Scales of goodness of expressions are shifted relative to English: "good" (gut) to a German means "it totally fulfills all my needs and expectations, so it is perfect for my purpose". "very good" (sehr gut) means "it exceeds all my expectations" and to a German already sounds like total hyperbole. Anything like "delightful" or "excellent" to a German sounds either totally sleazy or sarcastic.
When something is not perfect but adequate and we are happy with it, we would say something like "not bad", "it's fine" or "you can leave it like that". Which to the english speaking world has totally different connotations and can lead to rather interesting misunderstandings.
And especially "not bad" ("nicht schlecht") can be confusing in that it is sometimes something rather positive. It, in German and said in the right tone of voice" can mean "this is suprisingly good".
All the issues basically boil down to "nobody wants to do the busywork of CVE filtering, triage, rejections, changes".
As a developer, kernel or otherwise, you get pestered by CVE hunters who create tons of CVE slop, wanting a CVE on their resume for any old crash, null pointer deref, out of bounds read or imaginary problem some automated scanner found. If you don't have your own CNA, the CVE will get assigned without any meaningful checking. Then, as a developer, you are fucked: Usually getting an invalid CVE withdrawn is an arduous process, taking up valuable time. Getting stuff like vulnerability assessments changed is even more annoying, basically you can't, because somebody looked into their magic 8ball and decided that some random crash must certainly be indicative of some preauth RCE. Users will then make things worse by pestering you about all those bogus CVEs.
So then you will first try to do the good and responsible thing: Try to establish your own criteria as to what a CVE is. You define your desired security properties, e.g. by saying "availability isn't a goal, so DoS is out of scope", "physical attacker access is not assumed". Then you have criteria by which to classify bugs as security-relevant or not. Then you do the classification work. But all that only helps if you are your own CNA, otherwise you will still get CVE slop you cannot get rid of.
Now imagine you are an operating system developer, things get even worse here: Since commonly an operating system is multi-purpose, you can't easily define an operating environment and desired security properties. E.g. many kiosk systems will have physical attackers present, plugging in malicious hardware. Linux will run on those. E.g. many systems will have availability requirements, so DoS can no longer be out of scope. Linux will run on those. Hardware configurations can be broken, weird, stupid and old. Linux will run on those. So now there are two choices: Either you severely restrict the "supported" configurations of your operating system, making it no longer multi-purpose. This is the choice of many commercial vendors, with ridiculous restrictions like "we are EAL4+ secure, but only if you unplug the network" or "yeah, but only opensshd may run as a network service, nothing else". Or you accept that there are things people will do with Linux that you couldn't even conceive of when writing your part of the code and introducing or triaging the bug. The Linux devs went with the latter, accept that all things that are possible will be done at some point. But this means that any kind of bug will almost always have security implications in some configuration you haven't even thought of.
That weird USB device bug that reads some register wrong? Well, that might be physically exploitable. That harmless-looking logspam bug? Will fill up the disk and slow down other logging, so denial of service. That privilege escalation from root to kernel? No, this isn't "essentially the same privilege level so not an attack" if you are using SElinux and signed modules like RedHat derivatives do. Since enforcing privileges and security barriers is the most essential job of an operating system, bugs without a possible security impact are rare.
Now seen from the perspective of some corporate security officer, blue team or dev ops sysadmin guy, that's of course inconvenient: There is always only a small number of configurations they care about. Building webserver has different requirements and necessary security properties than building a car. Or a heart-lung-machine. Or a rocket. For their own specific environment, they would actually have to read all the CVEs with those requirements in mind, and evaluate each and every CVE for the specific impact on their environment. Now in those circles, there is the illusion that this should be done by the software vendors, because otherwise it would be a whole lot of work. But guess what? Vendors either restrict their scope so severely that their assessment is useless except for very few users. Or vendors are powerless because they cannot know your environment, and there are too many to assess them all.
So IMHO: All the whining about the kernel people doing CVE wrong is actually the admission that the whiners are doing CVE wrong. They don't want to do the legwork of proper triage. But actually, they are the only ones who realistically can triage, because nobody else knows their environment.
The CVE system would be greatly improved by a "PoC or GTFO" policy. CVSS would still be trash, but it'd simplify triage to two steps: "is there a proof-of-concept?" and "does it actually work?". Some real vulns would get missed, but the signal:noise ratio of the current system causes real vulns to get missed today so I suspect it'd be a net improvement to security.
But you cannot PoC most hardware and driver related bugs without lots of time and money. Race conditions are very hard to PoC, especially if you need the PoC to actually work on more than one machine.
So while a PoC exploit does mean that a bug is worthy of a CVE, the opposite isn't true. One would overlook tons of security problems just because the discoverer of them wasn't able to get a PoC working. But it could be worth it, to maybe also keep the slop out.
The alternative is to treat all bugs as security bugs, which is valid since they by definition prevent the expected functionality of the program and are thus at least a DoS. This is essentially what Linux does. People don't like this because they often don't care about DoS bugs and it makes the CVE system pretty useless if they only want to see other sorts of security issues.
Depends on the location, but around here solar for heating is completely useless.
In Germany (which is farther south than the nordics and gets far more sunlight), solar panels are already insufficient for heating half of the year. On a typical single-family home, you will get at most 10kW peak power solar on the roof, which you can reach in the summer months when there are no clouds. In winter, those 10kWp will generate at most 5kWh of energy per day. Which is a factor of 4 to 5 below the 20 to 30kWh per average day for heating (with generous insulation). The farther north you go, the worse this gets. Half of the nordics get essentially no sun at all in winter, and are quite a bit colder than Germany.
So you need something other than the sun to heat your home in winter. A heat pump can double, maybe triple the solar energy you might get on sunny winter days, but that doesn't usually cut it. So you need grid electricity, wood or fossil fuels. And when electricity prices are as low as in the nordics (around or below 20ct/kWh), heat pumps are totally viable.
Adding solar can be sensible for cooling in the summer months, and maybe a bit of hot water, and heating in late spring, early autumn. But for winter? Totally useless.
And while you could do long-term storage, that will cost you several arms and legs, tons of space and a huge maintenance hassle. And if anything should go wrong with your storage, you have no heat all winter and better have an emergency plan...
There's a surprising amount of earth architecture in Germany. The walls are your storage ... not enough to last all winter, and not enough to make your house actually "warm", but enough to provide a baseline that smooths over energy availability issues.
Of course, it works even better with higher levels of insolation, since the exterior surfaces of the walls receive more energy during the day.
Steam and hot water pipes are extremely expensive to install, far worse than electricity, fibre, water or sewage.
You need to be more leak-proof than cold water pipes, because loss of pressure with steam and hot water is much more of a problem than with cold water and cannot easily be solved by just adding more cheap water. Pipe materials have to be more resistant to corrosion because higher temperatures and pressures make them corrode so much faster than with cold water. Closed hot water/steam circuits also mean that there won't be a protective limescale coating on the inside. You need insulation that you can bury and which will last for at least 40 years, which is even more expensive than the pipes. And the insulation will double the pipe diameter. And the insulated pipes have a larger keepout area that needs to be kept free of rocks, other pipes and mechanical strain because the insulation is soft and sensitive to those things. Since usually the pipes aren't operated in summer, and since generally thermal variance is far higher than with cold water, thermal expansion needs to be taken into account, so you need expansion corners, sliding sections, different valve constructions that are tight in all temperatures, etc.
And even with perfect insulation, you will loose approximately 30 to 40% of heat in your piping. So all of this is only viable if you don't care about the cost of the heat, your consumers can (be forced to or persuaded to) accept at least 30% higher prices per kWh compared to their local boiler, not to mention the capital cost.
There are only some areas in Europe even, where those kinds of installations take place: Densely packed inner cities with largely rented-out flats in appartment buildings. There, the landlords/owners avoid the cost and risk of a local boiler and don't care about the running cost of heat, because they don't pay for it. In smaller towns, like in the example, mostly public buildings like schools use those kinds of district heating systems, because the municipality doesn't care as much about cost of the heat, and more about cost of maintenance of a hundred local boilers vs. one centralized system. And in the end, it's taxpayers' money, so they don't actually care that much, headlines and opening ceremonies are more important than that.
Individual home owners usually do have their local systems, which can be run cheaper than what district heating will charge you. And since city density is lower and home ownership is more widespread in the US, district heating is even less competitive there.
> And even with perfect insulation, you will loose approximately 30 to 40% of heat in your piping.
At least here in Finland the norm is losses in the range of 5-20%, with the upper end of the scale for smaller scale networks with smaller diameter piping and low flow rate. In the larger cities losses are closer to the low end of that scale.
In the summer when the consumption is very low (essentially only hot tap water production) losses can rise up to 50%.
lots of industrial processes produce waste heat that can't easily be turned into energy, so the comparison isn't to a boiler, but to not having the heat.
It is true that the heat can be used if it is there anyways. But usually not in a big city-wide network. Instead a more localized, larger consumer is far better, because running the hot water network is far too expensive. For example, large producers of heat like data centers, dairy processing or chemical plants around here deliver their heat to public swimming pools, schools or greenhouses that are intentionally built nearby.
Even the grandparent's article says so if you read carefully: "A large portion of the town’s own buildings, including the municipal school, town hall, and library, are connected to the district heating network.". They didn't even attach all of the public buildings. Not to mention about the rest of the town.
That's exactly what I was thinking of. Cogeneration plant goes up right next to datacentre, and then various municipal services are built near that - including other factories, high density commercial and high density residential that can take advantage of cogeneration and use district heat. In particular commercial and industrial uses actually do need heat in the summer.
In some areas, natural-gas fired cogeneration only is really necessary in the winter during dark months/cold weather - which is an ideal situation to be producing district heat.
Because for timing-sensitive code, those are important. If a variable is really a register, cache-based timing attacks just don't happen, because there is no cache in between.
Only locally, only for you, and only short term. You are wasting the time of the person you are asking, and you are learning absolutely nothing about the context of the answer. When the next question arises, you won't even know where to look, you will only continue wasting other peoples' time.
That's a false assumption that the man page even has the info you need. There are channels to write bugs against code, but almost nothing to file bugs against man pages. That's not even a concept to most people, that it's a bug when you apply a use case (say, to apply eui-64 to SLAAC in IPv6 in order to generate a consistent address) and cannot find the information using the man page. If you filed a bug that the man pages failed you nobody would fix it because it's not sexy, glamorous work. Its easier to tell someone to RTFM.
In this case, you would have to already know about the existence of eui-64 to know that is what you want. I've seen this many times, you have to know what the thing is already, or know what the answer is to your problem, in order to find it in the man page.
Total waste of my time. I don't care if it's free or was created by volunteers, that isn't absolution of criticism when it represents something and fails to deliver it.
Nonetheless, you are expecting other people to know the manpage and read it for you. That is a game you may be able to play with paid support, but usually not even there: They will be more wordy and polite, but in essence tell you to RTFM as well.
Bugs in Perl modules that are documentation related are normal bugreports and patches in the normal patch flow because documentation is embedded as POD within the source code.
Your example is very specific and weird (and maybe not even Perl-related). From which you deduce that it is OK to waste the time of volunteers because once one manpage failed you and you decided to never read any manpages again. You only seem to care about your own time, not anyone else's. That is not how anything works on this planet, either you deal with volunteers, where you have to make them care about your query by being considerate, friendly and respect their time as well as you would like yours respected. Or you are dealing with paid support, in which case you have to make them care by paying them for their time by the hour.
You don't need to turn off STP, usually it's enough to set the forward delay to a very small value ("port fast" in cisco commands). If there is a loop, the port will usually still detect it, you at the most get a handful of multiplied packets.
And all the "http boot" firmware I've seen either always ignores certificate errors or doesn't do TLS anyways.
Yes, but then you need to select the proper menu option at boot time. Sometimes just moving the hardware stack one to the left and swapping the cables is quicker.
But since all the networks since 4G, there is no more low-level network support for things like SMS. Everything, including voice and messages, is IP- and packet-based. So the only thing the carrier does anymore is to authenticate that IP connection through your SIM card and bind your identity to the phone number. It actually doesn't really matter if messages are "network native" or through a third-party app, there is no more guaranteed timeslot and reliable delivery that SMS used to have.
And nowadays, RCS is also outsourced to Google by basically every carrier.
So RCS is the same as WhatsApp et al., only that the app you are using doesn't tell you that Google will monitor all your communications in addition to the monitoring your carrier does...
It doesn't really matter what the encapsulation is/was, the values of a federated protocol the carrier participates in directly remain the same. The downside is you bundle the privacy to your carrier but that concern should really be solved with E2EE, not trust in a given provider. The upside is your communication service status is tied to your connection service status, and federated out immediately from there. You also gain the ability to fallback transparently to SMS/MMS in the exact same way RCS would work.
Google botched up RCS a bit in order to get it momentum, but plenty of carriers do support RCS natively as that's the only way Apple did it with iOS. Google did at least push E2EE options, but those only landed in GSM with RCS Universal Profile 3.0 and I don't think Apple has given a date for when they will support that profile on iOS. That is to say, the problems here are not inherent to RCS itself but the typical adoption and rollout problems of communication protocols.
All that aside, I'd gladly sacrifice the federated service provider flow if there were actually an equally popular federated solution to latch on to with full fallback capability to aid the remaining transition (+ the protocol actually be designed with radio power saving in mind). It's just RCS is by far the closest thing to that full package vs any other generic data messaging service.
> Google did at least push E2EE options, but those only landed in GSM with RCS Universal Profile 3.0 and I don't think Apple has given a date
This is my guess also. It was published in March[1] this year and I think it was too late to include in this year's iOS 26 release, so possibly iOS 27.
They have promised to implement it:
> "End-to-end encryption is a powerful privacy and security technology that iMessage has supported since the beginning, and now we are pleased to have helped lead a cross industry effort to bring end-to-end encryption to the RCS Universal Profile published by the GSMA," said an Apple spokesperson. "We will add support for end-to-end encrypted RCS messages to iOS, iPadOS, macOS, and watchOS in future software updates." [2]
Scales of goodness of expressions are shifted relative to English: "good" (gut) to a German means "it totally fulfills all my needs and expectations, so it is perfect for my purpose". "very good" (sehr gut) means "it exceeds all my expectations" and to a German already sounds like total hyperbole. Anything like "delightful" or "excellent" to a German sounds either totally sleazy or sarcastic.
When something is not perfect but adequate and we are happy with it, we would say something like "not bad", "it's fine" or "you can leave it like that". Which to the english speaking world has totally different connotations and can lead to rather interesting misunderstandings.
And especially "not bad" ("nicht schlecht") can be confusing in that it is sometimes something rather positive. It, in German and said in the right tone of voice" can mean "this is suprisingly good".