WEBVTT 00:00.000 --> 00:05.740 This is a weekly summary of interesting news that is relevant for my lectures at 00:05.740 --> 00:10.800 the Eastern Switzerland University of Applied Sciences. My name is Thomas 00:10.800 --> 00:19.340 Bocek and today we will discuss nine topics. The first article is the 00:19.340 --> 00:26.720 following here. Here it's a CTO at a customer support software company 00:26.720 --> 00:33.560 published this article about how AI coding tools changed their work in 00:33.560 --> 00:39.360 recent months. The author claims productivity increased by two to three 00:39.360 --> 00:47.560 times compared to before. The interesting part is not how much the CTO codes but 00:47.560 --> 00:54.780 the key shift is in what the work involves. Previously CTOs who wanted to 00:54.780 --> 01:00.660 code had to write every line themselves. Now AI tools handle code 01:00.660 --> 01:06.480 generation while the human provides context and makes decisions. For example 01:06.480 --> 01:12.900 the author can tell an AI tool to build a data export matching existing formats 01:12.900 --> 01:17.760 with additional fields and the tool generates most of the code correctly and 01:17.760 --> 01:23.400 this works because the author knows the codebase architecture and requirements 01:23.400 --> 01:29.780 while an unfamiliar engineer would spend much more time on the same task. And the 01:29.780 --> 01:35.720 author argues AI tools have not replaced technical judgment or system knowledge. 01:35.720 --> 01:41.620 Instead these skills became more valuable because they let you direct AI 01:41.620 --> 01:47.540 tools effectively. The role transformed from manual coding to providing 01:47.540 --> 01:53.940 specifications, evaluating AI generated solutions and making technical decisions. 01:53.940 --> 02:01.220 The author emphasizes that deep context about the system is what makes this 02:01.220 --> 02:10.780 productivity gain possible. The next article this one is in German. Here the 02:10.780 --> 02:19.900 Swiss army had seven IT projects in critical status by mid 2024 and the 02:19.900 --> 02:24.940 Parliament's finance delegation warned of potential billion franc in 02:24.940 --> 02:31.500 damages. By late 2025 five of these seven projects returned to an acceptable 02:31.500 --> 02:37.540 status and the army's new cyber command made a major change in project 02:37.540 --> 02:42.300 management methods. They stopped using traditional five-year project cycles 02:42.300 --> 02:47.920 with multiple hierarchy levels and switched to Scaled Agile Framework which 02:47.920 --> 02:53.260 we also teach here at OST. This is an agile project management approach that 02:53.260 --> 02:59.220 has been used in IT companies for about twenty-five years. Finally it arrived at the Swiss 02:59.220 --> 03:05.220 army. Under the new method development teams work in sprints of two weeks each 03:05.220 --> 03:12.300 after five sprints all participants meet in a big room planning session. They 03:12.300 --> 03:17.180 review what was achieved, assess the current status and decide next steps. 03:17.180 --> 03:23.100 Then another five sprints follow. The program leader states they now work 03:23.100 --> 03:27.900 step-by-step with close involvement of end-users instead of having suppliers 03:27.900 --> 03:32.980 work for five years and potentially deliver something that does not fit 03:32.980 --> 03:39.040 requirements. The focus shifted to iterative cycles with regular validation 03:39.040 --> 03:48.060 rather than long-term parallel projects. The next article is the following here 03:48.060 --> 03:55.140 it's about AWS and this is about a monitoring platform company. They published 03:55.140 --> 04:01.460 a follow-up report two years after moving their infrastructure from AWS cloud to 04:01.460 --> 04:07.300 bare-metal servers in data centers. The company now reports annual savings of 04:07.300 --> 04:13.860 1.2 million dollars compared to their previous AWS costs which is 76% less than 04:13.860 --> 04:19.940 they would pay on AWS. The company runs their systems on physical servers 04:19.940 --> 04:24.820 they own located in colocation facilities in Paris and Frankfurt. They 04:24.820 --> 04:29.020 use open source software including Kubernetes for container management and 04:29.020 --> 04:36.540 Ceph for distributed storage. The infrastructure has maintained 99.993% 04:36.540 --> 04:42.100 availability over 730 days of operation. The company states their 04:42.100 --> 04:49.860 uptime was better than AWS noting they avoided region-wide AWS outages that I 04:49.860 --> 04:55.220 covered the last time. The migration required approximately one week of 04:55.220 --> 05:01.260 engineering time. Ongoing maintenance takes about 14 engineer hours per month 05:01.260 --> 05:07.020 which includes kernel updates, storage system checks and Kubernetes upgrades. 05:07.020 --> 05:12.380 The company states this is similar to the time they previously spent on AWS 05:12.380 --> 05:18.620 cost optimization and configuration management. The company addressed 05:18.620 --> 05:24.980 concerns about hardware failure risks by deploying servers across two different 05:24.980 --> 05:29.540 data centers with different power providers. They still use AWS for 05:29.540 --> 05:34.420 specific services like long-term backup storage and content delivery networks 05:34.420 --> 05:41.340 where cloud economics remain favorable. The article notes that cloud services 05:41.340 --> 05:46.020 remain the better choice for workloads with variable usage patterns, heavy 05:46.020 --> 05:51.540 reliance on managed database services or when teams lack infrastructure expertise. 05:51.540 --> 05:58.660 The company stayed on AWS for their first five years before the migration made 05:58.660 --> 06:09.020 economic sense. Now the next article it's the following here it's a BBC report 06:09.020 --> 06:16.180 and this happened on Wednesday. Microsoft Azure experienced a global outage that 06:16.180 --> 06:22.020 took down multiple services for several hours. Azure is Microsoft's cloud 06:22.020 --> 06:27.460 computing platform and holds approximately 20% of the global cloud 06:27.460 --> 06:33.580 market. The outage affected many services. Microsoft stated the cause was an 06:33.580 --> 06:39.140 wrong configuration change that led to DNS issues. The company restored service 06:39.140 --> 06:44.340 by rolling back to a previous update and this outage occurred one week after a 06:44.340 --> 06:51.180 similar AWS outage caused by the same root cause, DNS problems. These recent incidents highlight 06:51.180 --> 06:55.900 how concentrated cloud infrastructure has become. Just imagine Microsoft, 06:55.900 --> 07:03.060 Amazon and Google have a big outage that means this can disable hundreds or 07:03.060 --> 07:08.140 thousands of applications simultaneously. 07:08.140 --> 07:16.980 The next article is about the European Commission. It's this report here. The 07:16.980 --> 07:22.940 European Commission published a report in October 2025 on submarine cable 07:22.940 --> 07:29.020 security which is a topic I also talk in my distributed systems lecture. The report 07:29.020 --> 07:34.820 addresses critical infrastructure that carries approximately 97 to 98 percent of 07:34.820 --> 07:40.860 global internet traffic. The report identifies several infrastructure 07:40.860 --> 07:46.860 vulnerabilities. Europe has over 300 submarine cable landing stations but 07:46.860 --> 07:52.460 still depends on a few critical points. The Red Sea remains a bottleneck where 90 07:52.460 --> 07:58.100 percent of traffic between Europe and Asia passes through. Some island member 07:58.100 --> 08:03.260 states like Cyprus, Ireland and Malta rely almost exclusively on submarine 08:03.260 --> 08:09.540 cables for internet connectivity. The report examines market concentration 08:09.540 --> 08:16.140 risks. US hyperscalers already own 90 percent of total capacity on cables 08:16.140 --> 08:20.540 connecting the US and Europe and are increasing their share on Europe to 08:20.540 --> 08:26.140 Africa and Europe to Asia routes. Traditional European telecom operators 08:26.140 --> 08:30.940 have decreased their investment in cross-continental submarine cables. The 08:30.940 --> 08:36.620 report identifies supply chain dependencies. Europe has one major cable 08:36.620 --> 08:42.140 supplier Alcatel Submarine Networks in France but depends on non-EU entities 08:42.140 --> 08:48.540 for critical components. Optical fiber for long-haul cables comes exclusively 08:48.540 --> 08:54.220 from US and Japanese companies. Optical amplifiers in repeaters are manufactured 08:54.220 --> 09:00.380 only by US companies. Microchips for transponders are largely controlled by 09:00.380 --> 09:06.620 Taiwan and South Korea. Regarding maintenance capability the report notes 09:06.620 --> 09:11.860 that cable repair capacity faces pressure from an aging maintenance fleet 09:11.860 --> 09:16.860 and increased total cable length installed by hyperscalers. Some repair 09:16.860 --> 09:22.300 vessels have been repurposed for installation to meet deployment demand 09:22.300 --> 09:28.380 which absorbs repair resources. The report developed seven risk scenarios 09:28.380 --> 09:33.660 ranging from coordinated physical attacks on cables to supply chain 09:33.660 --> 09:38.620 disruptions and natural events. These scenarios include escalation stages for 09:38.620 --> 09:47.300 stress testing infrastructure resilience. The next article is about React Server 09:47.300 --> 09:54.420 Components. It's the following here. I talked about improving SSR and CSR in the 09:54.420 --> 10:00.700 Application Architecture lecture and I mentioned React Server Components. Here 10:00.700 --> 10:07.100 in this article a developer reports on one year using React Server Components 10:07.100 --> 10:13.300 in Next.js and their migration to TanStack Start. React Server Components 10:13.300 --> 10:18.940 split code into server and client parts. Server components run only on the 10:18.940 --> 10:24.740 backend and can access databases directly. Client components handle user 10:24.740 --> 10:29.940 interactions. The problem is client components can also run on the backend 10:29.940 --> 10:36.420 making the naming confusing. The team found several issues. First, optimistic 10:36.420 --> 10:41.500 updates became nearly impossible because server components cannot change after 10:41.500 --> 10:47.060 loading. This forced splitting code into multiple files awkwardly. Second, every 10:47.060 --> 10:51.620 page navigation required fetching from the server even when the browser already 10:51.620 --> 10:57.940 had the needed data. This made navigation slower than necessary. Third, layouts had 10:57.940 --> 11:03.100 artificial restrictions that made data sharing between components harder. 11:03.100 --> 11:08.700 Fourth, the system sends page content twice once as HTML and once as a special 11:08.700 --> 11:14.500 format for React doubling bandwidth usage. The team migrated incrementally to 11:14.500 --> 11:19.540 TanStack Start by creating stub implementations of Next.js APIs. They 11:19.540 --> 11:24.780 redirected Next.js imports to their own implementations using Vite configuration. 11:24.780 --> 11:30.460 After migration their site was faster in development had better page load times 11:30.460 --> 11:34.220 quicker navigation and cost less than their deployment with Vercel. And 11:34.220 --> 11:39.820 in the lecture I showed many improvements to client-side rendering 11:39.820 --> 11:43.660 and this article is also about these trade-offs. The next article is about 11:43.660 --> 11:50.580 Kafka. It's the following here. A developer benchmarked PostgreSQL as a messaging 11:50.580 --> 11:57.020 system to challenge the assumption that specialized tools like Kafka are always 11:57.020 --> 12:03.500 necessary. The tech industry often adopts complex distributed systems when simpler 12:03.500 --> 12:08.860 solutions would work. Two trends support this view. The small data movement 12:08.860 --> 12:14.340 recognizing most workloads are smaller than assumed and the PostgreSQL 12:14.340 --> 12:20.620 renaissance showing one database can handle many use cases. The author tested 12:20.620 --> 12:26.020 PostgreSQL in two scenarios. First, as a publish-subscribe system where multiple 12:26.020 --> 12:31.660 readers consume the same messages. They created tables that work like Kafka's 12:31.660 --> 12:36.740 log structure with monotonically increasing offsets. Writers insert batches 12:36.740 --> 12:42.620 of messages while readers poll for new data in consumer groups. A small four CPU 12:42.620 --> 12:47.620 PostgreSQL instance handled five megabytes per second writes and twenty-five 12:47.620 --> 12:51.940 megabytes per second reads. A three node replicated setup maintained similar 12:51.940 --> 12:57.900 throughput with acceptable latency increases. A large ninety-six CPU instance reached 12:57.900 --> 13:05.620 two hundred forty megabytes per second writes and over one gigabyte per second reads. Second, as a 13:05.620 --> 13:11.460 queue system where each message gets processed once using SELECT FOR UPDATE 13:11.460 --> 13:17.020 SKIP LOCKED for row locking, a four CPU instance processed nearly three thousand 13:17.020 --> 13:23.140 messages per second. The replicated setup maintained over two thousand messages per 13:23.140 --> 13:28.820 second. The larger instance reached twenty thousand messages per second and the author 13:28.820 --> 13:35.220 argues most companies operate at scales where PostgreSQL performs okay. The 13:35.220 --> 13:40.140 organizational overhead of adopting specialized systems, learning, monitoring, 13:40.140 --> 13:45.700 deployment processes, operational expertise often outweighs performance gains at 13:45.700 --> 13:55.620 small scale. And the next article is about supply chain attacks. It's the 13:55.620 --> 14:03.380 following article here. Security researchers discovered a campaign 14:03.380 --> 14:08.820 called PhantomRaven that exploited a weakness in NPM, the package manager for 14:08.820 --> 14:13.580 JavaScript. Attackers uploaded over one hundred malicious packages to 14:13.580 --> 14:21.740 NPM that were downloaded more than eighty-six thousand times since August. The attack 14:21.740 --> 14:27.020 exploited Remote Dynamic Dependencies, a feature that allows packages to download 14:27.020 --> 14:32.460 code from external websites during installation. Normally dependencies come 14:32.460 --> 14:38.020 from NPM's trusted servers and are visible to developers. But Remote Dynamic 14:38.020 --> 14:42.420 Dependencies can fetch code from untrusted domains even over unencrypted 14:42.420 --> 14:48.140 HTTP connections. The malicious packages showed zero dependencies to developers 14:48.140 --> 14:53.740 and security scanners hiding the fact that they downloaded harmful code from 14:53.740 --> 14:59.300 attacker controlled servers. And this design creates additional risks beyond 14:59.300 --> 15:03.860 hiding malicious code. Attackers can serve different payloads based on who 15:03.860 --> 15:08.460 requests them. They could send clean code to security researchers while 15:08.460 --> 15:12.820 targeting corporate networks with malicious versions. They could also serve 15:12.820 --> 15:17.780 legitimate code initially to pass security scans then switch to malicious 15:17.780 --> 15:23.300 code later. The malicious dependencies collected sensitive data from infected 15:23.300 --> 15:28.380 machines including environment variables, credentials for GitHub, Jenkins and NPM 15:28.380 --> 15:33.180 and information about continuous integration systems. And this stolen data 15:33.180 --> 15:40.020 could enable follow-on supply chain attacks. Many malicious packages used dependency 15:40.020 --> 15:44.980 names that AI chatbots hallucinate when developers ask for coding help. 15:44.980 --> 15:49.500 Developers trust these AI suggestions and install packages with those names 15:49.500 --> 16:00.020 unknowingly downloading malware. And the last article, this is about blockchain 16:00.020 --> 16:06.460 and it's the following article here. Romania banned Polymarket, a prediction 16:06.460 --> 16:13.020 market platform for operating as an unlicensed gambling service. The National 16:13.020 --> 16:17.020 Office for Gambling blacklisted the platform after trading volume exceeded 16:17.020 --> 16:22.140 six hundred million dollars during Romania's presidential and local elections. 16:22.140 --> 16:28.180 Polymarket gained attention during the twenty twenty-four US presidential election when it 16:28.180 --> 16:31.660 showed different odds than traditional polls for the Trump versus 16:31.660 --> 16:36.580 Harris race. You may remember seeing these predictions online and this 16:36.580 --> 16:41.820 platform allows users to bet on political outcomes using cryptocurrency. 16:41.820 --> 16:47.500 Romanian regulators stated that Polymarket operates counterpart betting 16:47.500 --> 16:54.180 where users wager money against each other on future event outcomes. This qualifies as 16:54.180 --> 17:00.000 gambling under Romanian law regardless of using blockchain or cryptocurrency. 17:00.000 --> 17:05.700 The platform lacked required licenses and failed to implement fiscal reporting, 17:05.700 --> 17:11.220 player protection mechanisms and anti-money laundering oversight. Polymarket 17:11.220 --> 17:17.140 calls itself an event trading platform but regulators argued its structure meets 17:17.140 --> 17:23.300 all legal definitions of gambling. Users bet money on uncertain outcomes while 17:23.300 --> 17:27.740 the platform takes a commission. Romanian internet providers must now block 17:27.740 --> 17:35.660 access to the site. This follows similar regulatory actions in 17:35.660 --> 17:40.380 multiple countries. The United States Commodity Futures Trading Commission 17:40.380 --> 17:46.860 fined Polymarket in twenty twenty-two for operating unregistered derivatives 17:46.860 --> 17:52.220 markets, forcing it to block American users. Belgium, France, Poland, Singapore 17:52.220 --> 17:58.460 and Thailand also restricted access. Despite these restrictions, Polymarket 17:58.460 --> 18:04.860 recently secured a two billion dollar investment from Intercontinental Exchange which 18:04.860 --> 18:10.380 owns the New York Stock Exchange and the platform plans to resume limited 18:10.380 --> 18:15.460 trading in the United States within weeks, focusing initially on sports 18:15.460 --> 18:21.220 markets. This follows a recent no-action letter from the CFTC clearing the way 18:21.220 --> 18:28.380 for relaunch. That's it for this week, see you next week.