Yes, the free republic of wendland was established in 1980: https://en.wikipedia.org/wiki/Free_Republic_of_Wendland
The battle of brokdorf was also in the 80ies: https://www.helmut-schmidt.de/en/publications/detail/the-bat...
HN user
Yes, the free republic of wendland was established in 1980: https://en.wikipedia.org/wiki/Free_Republic_of_Wendland
The battle of brokdorf was also in the 80ies: https://www.helmut-schmidt.de/en/publications/detail/the-bat...
* If the cold war had turned into a hot war, almost all of Germany would have been nuked. The expectation was not to be able to stop the soviet invasion, but to nuke them in western Germany.
* The nuclear industry in Germany was plagued by scandals and big parts plain criminal: https://www-deutschlandfunkkultur-de.translate.goog/hanau-de...
* And ineptitude was common: https://en.wikipedia.org/wiki/Asse_II_mine
EDIT: The reaction of the state also caused an escalation. The constitutional court blocked governmental overreach: https://www-bpb-de.translate.goog/kurz-knapp/hintergrund-akt... This also lead to the anti nuclear movement being about more than just nuclear plants, but rights for citizens.
If it was only "my" system without any integrations, I might agree.
But currently e.g. I am working on an MES/Scada layer that integrates data from a load of different machines in a factory. These machines are from China, Korea, Germany, Sweden ... Upwards there is an ERP integration (and some other systems).
Sometimes machines are updated and suddenly behave differently. Giving error messages in Chinese.
The ERP has the nasty behavior of returning error messages where it is not clear whether the actual processing actually happened or not. There are some heuristics on parsing the error messages, but these also change with new versions.
Sometimes one machine overloads cloud infrastructure and completely unrelated functionality fails.
Sometimes the on-premise network stops working for whatever reason and data is lost.
Sometimes operators do not understand a perfectly valid error message like: "The batch you loaded into input position XY has expired on XZ and cannot be used for production": "But we have been told to use it..."
So when you get called out at night, because the production line stopped and "MES is displaying an error message", it is mostly about finding out what integration failed and who else to wake up. Getting this right is very much appreciated by your colleagues.
And this is where you need a mental model of how things are connected, what error message happens because of what external causes etc.
Observability can only work perfectly for known problems. In a complex system for unexpected problem you can either provide too much data, so analyzing it and finding the relevant part becomes really hard, or too little data which makes finding the issue impossible.
There are so many companies claiming to provide the perfect observability solution and there are certainly solutions that help. But it is all very far from perfect.
Not relying on people is managers wet dream. And for a lot of people it might be true that they can be easily replaced. But for complex systems there are always some key people that you cannot replace without causing issues.
"The deeper the prompt, the better the code actually gets."
.... and in the and you end up with a very deep prompt that exactly specifies the behavior. This is what a programming language is.
I'd rather describe a data structure in a language designed for this task, than a prompt the might be interpreted in many different ways.
"It’s about attention and understanding. To keep my attention, I must go beyond ‘read code’ like a passive observer of agents from afar. To really connect with the architecture of the system, it helps to truly experience the code"
I guess the funny answer that is behind this sentence is: You have to train your own mental model. We always argue about code in a very abstract and logical manner. But when coding the subconsciousness makes most of the decision ("this just feels right"). But for this to work you have to train it. And this does only work in a very limited way with code reviews or reading documentation. It requires repetition and deep focus.
When there is an issue in production with this mental model you will be able to point to the cause of an error message instantly. With generated code you'll search for a long time with your slow, conscious part of the brain.
For LLMs to be really helpful, they have to take over complete maintenance of the code. So you can treat them like an external library: Just assume it works. Otherwise this will always be problematic.
Keypoint: "Co-founder Larry Ellison has fallen behind the Google co-founders, Amazon’s Jeff Bezos and Michael Dell on the list of the world’s richest people."
Yes, this is the important question of our time. Who is highest on some imaginary list of value?
My problem with AOP has always been that it makes the simple case trivial and the hard case much harder.
Looking at transactions: The 99% solution is trivial: Every service call is a transaction. AOP can save me a few lines for every method and things look much cleaner.
But then comes the huge excel upload that is performance critical. Batch more service calls to fetch additional information in the background, commit every so-and-so records in a loop depending on the data size, do a custom roll-back if things fail.
And suddenly this whole separation of concerns breaks down and creates a huge mess.
The simple case saves a few minutes, the complicated case causes weeks of depression. Not a good tradeoff from my experience.
An LLM adding to the confusion by only sometimes getting things right and explaining that the separate documents are always valid, except when they are not, well, sounds like a fun experience.
Nuclear in 2006 was 160TWh. Coal in 2025 was 93TWh. So a big portion of nuclear would have been replaced by renewables by now anyways (natural gas has a different role in the grid and cannot be replaced bu nuclear).
https://energy-charts.info/charts/energy/chart.htm?l=en&c=DE...
Also a lot of coal plants have been / are used in district heating in addition to electricity. Replacing them is much harder and takes longer than nuclear which is electricity only. Shutting those down was never a short term option.
Calling it the worst decision ever is really funny, when it really is just a question of the order of the transition to renewables. And much of that order was dictated by technical needs.
It is working perfectly fine: https://energy-charts.info/charts/energy/chart.htm?l=en&c=DE...
Heat pumps and electric cars are so much more efficient than ICE engines or gas heating. This is why the share doesn't change a lot. Even looking at consumption in Norway: https://robbieandrew.github.io/EV/img/NORenergy_road.svg You don't see the electric share going up a lot. Still oil consumption is collapsing-
I write code. On a good day perhaps 800-1000 "hand written" lines.
I have never actually thought about how much typing time this actually is. Perhaps an hour? In that case 7/8th of my day are filled with other stuff. Like analysis, planning, gathering requirements, talking to people.
So even if an AI removed almost all the time I spend typing away: This is only a 10% improvement in speed. Even if you ignore that I still have to review the code, understand everything and correct possible problems.
A bigger speedup is only possible if you decide not to understand everything the AI does and just trust it to do the right thing.
I guess everyone dealing with legacy software sees code as a cost factor. Being able to delete code is harder, but often more important than writing code.
Owning code requires you to maintain it. Finding out what parts of the code actual implement features and what parts are not needed anymore (or were never needed in the first place) is really hard. Since most of the time the requirements have never been documented and the authors have left or cannot remember. But not understanding what the code does removed all possibility to improve or modify it. This is how software dies.
Churning out code fast is a huge future liability. Management wants solutions fast and doesn't understand these long term costs. It is the same with all code generators: Short term gains, but long term maintainability issues.
That is a completely different level. I expect a Junior Developer to be able to completely replace me long term and to be able decide when existing rules are outdated and when they should be replaced. Challenge my decisions without me asking for it. Being able to adapt what they have learned to new types of projects or new programming languages. Being Senior is setting the rules.
An LLM only follows rules/prompts. They can never become Senior.
A Junior programmer is a total waste of time if they don't learn. I don't help Juniors because it is an effective use of my time, but because there is hope that they'll learn and become Seniors. It is a long term investment. LLMs are not.
I didn't want to put the usability of the motor into question or go into a complete evaluation of advantages/disadvantages :) This was just an explanation that weight trimming the motor might be very much worth the effort - even if it somewhat "insignificant" compared with savings that are possible in battery weight.
The issue with this type of motor is that it is part of the unsprung weight since it is inside the wheel. This is probably why savings here matter a lot more (or at least in a very different way) than the battery weight.
"In the era of AI and data-driven enterprises, reducing architecture debt will no longer be a technical choice. It will be a strategic differentiator that separates the companies that can transform from those that will fall behind."
Yeah. Whatever.
How is AI even related to architecture debt in software? By vibe coders forgetting to specify "decent architecture" in their prompt?
Same for data driven. For most companies data driven just means focusing on one more or less relevant metric, but ignoring all rational arguments on topics cannot be measured in an easy way. Leading to short term thinking and optimizing for a metric instead of for business success. Not great, but still not a lot to do with software architecture.
And as much as I'd love software architecture to be a strategic differentiator: It really is not. Companies need software that is good enough. Good and consistent architecture just lessens the developers pain in dealing with it (and technical/architecture improvements are much more fun to do, since there is no customer with strange requirements). There are many companies out there with horrible software quality that still succeed.
The long term strategy is H2:
https://h2-global.org/the-h2global-instrument/
And gas plants are what is closed to H2 and can be switched over easiest. But H2 is only viable once renewable production exceeds demands during long stretches of time. Otherwise it is always better to use the energy directly or use short term storage (batteries) which are also growing exponentially: https://battery-charts.de/battery-charts/
Sorry, you are all emotion and provide wrong statements. What I wrote directly contradicted your statements and proved them wrong, but now you say they are missing the point? Reducing fossil fuel consumption by 50% within 10 years is an achievement. There are always things that could be done in a better way. But let's be real here.
And yes Germany imports electricity from France: https://energy-charts.info/charts/energy/chart.htm?l=en&c=DE...
That is kind of the point of having an integrated grid.
But 19TWh. While producing 470TWh. 4%. That is not ... a lot. And in 2022 Germany exported 5.5TWh and had to restart coal plants when the French nuclear plants were in trouble. So what? That what a grid is for.
On short sightedness: https://www.dw.com/en/russian-gas-in-germany-a-complicated-5...
"Several commentators, business leaders and academics have identified that 1970 deal as a significant fork in the road of the Cold War, as it established a mutual basis for economic cooperation between Russia and western Europe." There are certainly different opinions on that. Gas imports started long ago and in the cold war that approach was working to some extend.
Only 13% of gas is actually used for electricity ("Stromversorgung"): https://www.bdew.de/service/daten-und-grafiken/erdgas-absatz... most of it was used as cheap energy source for chemical plants and other industry.
Germany didn't avoid nuclear by switching to renewables. It does so by burning coal and building gas-fired power plants.
That statement is plain wrong: https://energy-charts.info/charts/energy/chart.htm?l=en&c=DE... In 2013 about 300TWh of electricity came from fossil fuels, 92TWh from nuclear. In 2024 153TWh from fossil fuels and 0 from nuclear. So fossil fuels declined by 147TWh while nuclear only by 92TWh. Claiming that fossil fuels replaced nuclear is ridiculous, even after repeating it hundreds of times.
You can claim that keeping nuclear could have sped up the transition, but the inflexible nuclear plants could also have prevented people from investing in renewables, since the economics are worse if there is energy that is supplied permanently regardless of the price. Nuclear and renewables don't mix well.
https://www.fda.gov/medical-devices/safety-communications/do...
Existing smart watches that claim to do this are basically garbage. Just use a random number generator instead.
Apple and Samsung are supposedly working on it: https://www.forbes.com/sites/davidphelan/2025/01/26/samsung-... But it seems to be hard and from what I have seen the new Galaxy Watch 8 won't have this feature.
As a diabetic having alarms is the most important thing. Measurements are not that accurate (neither is the finger prick method: If sometimes get a difference of 20% comparing two measurements from both hands). But also the "ok" range of 3.8 mmol/L to 10 mmol/L is quite large and levels can rise/drop 20% in minutes. So it is still quite helpful.
With the CGM there is also an additional delay of about 15 minutes in the measurements. Mostly you want to be triggered when something strange happens and then you do a manual measurement to confirm.
A false alarm of low blood sugar is annoying, but it is a lot better than collapsing. You can relax a lot more if you know you will get an alarm.
As written above: This might be different for people with dementia or other issues that are not in a mental state to manage their diabetes.
From what I understand from the study the aim is to show that mass producing islet cells from stem cells is possible. Previously those where extracted from pancreases from dead people.
Having cells extracted from your own body has the advantage that there are a lot of they are not rejected by the immune system.
The reason the immune suppression is still needed is the cause of type 1 diabetes: It is a auto immune disease where the body attacks its own islet cells.
But this a specific immune reaction which could be easier to prevent than the generic rejection of cells from a different body. But this is not what this approach is trying to do for now.
This study just wants to show: This approach of creating islet cells work and it is worth trying to do a bigger more expensive study that can produce statistically relevant results.
"Curing" type 1 diabetis is still years off and that requires the immune issue to be solved as well.
Diabetes type 1 is quite well manageable if you have a CGM sensor and inject insulin regularly.
But if a person with dementia tends to peel of sensors, gets aggressive when getting injections etc. this might not work. And an unmanaged diabetes can be deadly.
Not sure how these approvals work in that case, but this groups of people might be the first that can benefit from a treatment like this.
https://listverse.com/2019/05/19/10-bizarre-calendar-fixes-t...
Everything before the introduction of the gregorian calendar is moot:
"In 1582, the pope suggested that the whole of Europe skip ten days to be in sync with the new calendar. Several religious European kingdoms obeyed and jumped from October 4 to October 15."
So you cannot use any date recorded before that time for calculations.
And before that it gets even more random:
"The priests’ observations of the lunar cycles were not accurate. They also deliberately avoided leap years over superstitions. Things got worse when they started receiving bribes to declare a year longer or shorter than necessary. Some years were so long that an extra month called Intercalaris or Mercedonius was added."
Besides that: find small (2-3 day) project ideas that require you to learn max. 1 new technology or idea, and build lots of such projects.
That's how you learn programming. It's not a bad idea, but at least for me software development is more about long term issues coming up, team communication, features that create short term value but long term problems. How to organize big piles of code.
A lot of abstractions don't make any sense in a 2-3 days project and you are better of hacking away a script than looking into "properly" modelling things.
My impression is always that as a junior you learn how to do stuff. Then you learn to do complicated stuff. And becoming a senior you learn how not to do complicated stuff.
This takes some of the fun out of it as well. Deploying a feature that is simple and that just works without any issues does not create nearly as much excitement as "saving the company" with a big hack and high risk deployments, although it is much better to not have to "save the company" in the first place.
AI might be nice to generate stuff. But as all code generators it has the issue of supporting the generated code long term.
With AI it is even worse: You don't get reproducible runs: Trying to fix a simple layout bug and suddenly some updated AI generates something completely different because it learned some new tricks and you cannot go back to what you had before and suddenly the whole page doesn't work anymore?
Sounds like fun!
Don't most applications that use threads also use thread pools because thread creation is expensive?
I guess these comparisons are nice to get a feeling how expensive operations are. But has it a lot real world relevancy?
In practice my beef with coroutines is that with unlimited concurrency you run into resource limits when the system gets some load (file descriptors, open connections, ... whatever the coroutine does that is limited) or starts a DOS attack. Which is something no one ever tests and something that appears randomly in production depending on the data fed to the system.
With many developers using them as default solution when things get slow that creates brittle systems. How is everyone else dealing with things like this?
Looking at demographics: https://en.wikipedia.org/wiki/Demographics_of_South_Korea in 1955 900.000 people were born in Korea. In 2022 about 250.000. The population in 2021 only decreased by 60.000 but this number will increase rapidly.
Seoul might not change for a few years but a population decrease of 1% each year will not leave the property market unaffected.
https://energy-charts.info/charts/installed_power/chart.htm?...
Please don't look at short term effects when trying to judge the energy transition. France might restart a coal plant because of issues with its nuclear plants. Germany restarts some coal plants to deal with the gas shortage and to export electricity to France. But this is short term. It is simply not possible to build new plants within one year to deal with the political changes.
The long term trends are stable. With the transition to electric vehicles (https://cleantechnica.com/2022/12/02/europe-electric-car-sal... ) fuel consumption should also soon start to fall in significant ways. Norway is already there with a decrease of 6.6% YoY (https://www.ssb.no/en/energi-og-industri/olje-og-gass/statis... ), the rest of Europe is probably trailing by about 5 years.
Of course everything should be faster and yes, the USA have to find their own way. It's not like even Spain and Sweden can have a similar approach to migrating to renewable energy.
On 1.: Birth rates are stable since about 1990 and declining since 2017: https://ourworldindata.org/grapher/annual-number-of-births-b... China had almost 30 million births in 1963, but only had 10 million last year.
The rate of population growth is decreasing much more quickly than expected: https://ourworldindata.org/grapher/population-growth-the-ann...
On 3.: In Germany the share of wind/solar in electricity production is more than 37%. How is this unproven? Supply is getting more stable almost every year: https://www.bundesnetzagentur.de/DE/Fachthemen/Elektrizitaet... Nobody is shutting off energy. And the EU has subventions for personally owned vehicles trying to increase their usage: https://ecf.com/news-and-events/news/money-bikes-financial-i...
"The simultaneous shutdown of 32,000 servers rarely occurs in the IT industry," Yang said.