rzwitserloot

I think you mean: If anybody anywhere decided to invoke a wait() until the state "my COMMIT; has been durably committed", then that means all previous commits must also be in durably committed state before we can continue.

Sure. But this doesn't affect other code that is merely wait()ing for 'logically committed'. Not in the past, and usefully, not in the future either. The 'logical system' can be far ahead of the 'durable' system, it doesn't have to wait.

Where it would go wrong is if code A needs to wait around for code B to do a thing (such as provide a value), and B's code for some reason contains a wait() on durable. Possibly because B was written before the split in commit behaviour was around, and for backwards compatibility reasons, for them COMMIT; means: "wait for durable commit".

Given that `SET synchronous_commit = off;` works per transaction, I'm kinda inspired here. I can think of a few places where we commit for various logical reasons but I don't need the fsync guarantee.

I'm pretty sure the costs of producing a fuel based solely on making it with electricity is by far, of all the options you named, best done with Ammonia.

The reason the cost of ammonia is barely better, or even worse, than things like methanol, is because the electricity process is still expensive.

But that can (and soon would!) become waaaay cheaper. Electricity __NOT__ on demand is dirt cheap and can be halved and quartered some more: Solar panels are _idiotically cheap_ these days and that state of affairs is not temporary.

We need more not-on-demand needs. As in, 'hey, uh, if theres some power left over cuz it's windy and sunny.. no prob! Let me run these ammonia producing machines at full power for a bit. No need for ammonia right now? No problem - compared to electricity, ammonia is vastly simpler to store'.

Ammonia is a great not-on-demand consumer of electricty. That's why this is necessary.

As you said:

> the cost of the green electricity dominates the economics over the process plant CAPEX anyway.

That's exactly the factor that can become ridiculously cheap. It isn't today because there's not much point investing in solar/wind because they do not cover on-demand needs (when it's not particularly sunny/windy, then electricity prices are sky high and you want to build electricity production that can deliver then. And solar/windy by definition can't), and the primary issue is transport.

if the demand for ammonia skyrockets, you can solve it all. Ammonia does not need to be produced on-demand, and you don't need all that much transport (build the ammonia producing plant close to your solar/wind parks).

In the modern bizarre age we find ourselves in...

A comedian is clearly the best job on your resume if you want to apply for the job of president.

Certainly the experience dealing with hecklers, and a sharp wit, come in handy.

> What if I claim need your data in a particular form in order to “interoperate” with you?

I read this as:

rzwitserloot is the operator of a SaaS service that has a bunch of data. Let's say, photos.

cbeach uses this law to request this data from rzwitserloot, and asks if it can be in .g3 format. It's _a_ format. Let's posit for a moment that it's burdened by patents, is unwieldy (produces really large files), converters are hard to find, and so on.

And your point is: HAHA! Because of dumb technocrats, GOTCHA!

And you'd be wrong. That's not what the law says.

I would tell you: Here are the files in jpg2k format, bzipped. These are common formats, they are how we store and use them, and it is a reasonable interpretation of the rule that I must provide this data in no undue delay in 'industry standard' standard formats. If you don't like it, sue me. And if you sue me, you would lose.

> s the EU legally compelling you to give away all your raw data to anyone that might want to cooperate / compete / sabotage / spy on you?

The exact data you need to provide is limited to that data which you host that is (also) owned by the requestor. I can't just ask, I dunno, facebook for the firehose of _everything by everybody_, I can only ask it for data that _I_ contributed to the platform. Other rules put limits on facebook contractually claiming ownership. Using this law to 'compete / sabotage / spy' is therefore difficult, and if it _is_ possible to meaningfully compete/sabotage/spy by using this law, then I posit that the service is rentseeking and needs to die. It is taking the 'value' of hoarding its network effect over others which is parasitising value out of the community and thus does not serve the broader interests. I can see a world where you want to financially incentivize companies to create network effect benefits, because you need to bankroll the creation if the system somehow, but doing so by giving its operators forever-rights on rentseeking the value created is perhaps a bit much. We have been doing that the past 20 or so and the results are catastrophic, which proves the point.

I _want_ a different attempt at it, and if that risks the pendulum swinging too far the other way, so be it. The EU and other law bodies have been practically screaming from the rooftops that they aren't happy with what IT companies are doing specifically in regards to e.g. hoarding their control of data to squash competition and reasonable use by the populace for years now, and they aren't moving.

This is how the world is supposed to work. You might want to check how e.g. the movie rating system came to pass. There wasn't one, the citizenry wanted one (we can debate whether the citizenry was correct in wanting that, not the point - they did), government threatened to write a law, and the business got the message and set up their own system. Government dutifully responded by not making a law.

When businesses start ignoring the strong hinting by government that laws will occur if they don't get in line, i.e. if they think they get to lord it over the populace and fall back to libertarian maxims to avoid all repercussion, the system fails. And here you are, advocating for just that.

This american defeatism about using laws and therefore just going with 'let the free market' decide is toxic and you need to cut it out. You can always find a case where a well meaning law has resulted in a disaster _and_ the blame can be laid squarely at the feet of the authors of the law, just as easily as finding a case where lack of laws has led to unbridled massive export of significant externalities to society and it is ridiculous that no law exists.

> Am I going mad here?

Well, take your pick. Mad, difficulty with understanding basic reading, or trolling. You're guilty of one of those 3.

That data sharing thing goes pretty far. Am I reading that correctly? Anything that is hosted in the EU, or sells to EU citizens, has to share _all (generated by activity, personal and non-personal, including meta-) data_ that the service itself can use (i.e. backup tapes are excluded), upon request, free of charge, without any obfuscation, and without much of a delay. For B2B and B2C.

Almost sounds too good to be true. As far as I can tell:

* There is no clause for restricting this if it's hard to do. If it's _a lot_ of data, you still have to provide it.

* There is no clause indicating you can charge a fee for the sharing of the data (this seems fair to me; the prep and transfer costs, assuming you automate the process, are incredibly low unless it's, I dunno, some 'permanently live stream my entire life in 4k' service). Easier to just eliminate any attempt at malicious compliance by interpreting 'reasonable' unreasonably.

Or to be overly dramatic: "Who has committed suicide because of her lies?", because we know that answer is not zero, and a direct consequence of her modus operandi of scorched earth legal warfare with anybody who steps out of line.

I'm in favour of being, as a society, so ambitious that you want to give all criminals a second chance, and in that sense, she deserves one.

But that's not, _at all_, how the US justice system is designed. If _she_ gets a second chance, that's.. a ridiculous injustice.

I've been toying with the idea of making something very very much lik this, but, for an existing language. Which makes it far, far more complicated; I'm sure various aspects of the design of whatever language one would build this for are needlessly convoluted due to not having been designed with this kind of editing in mind.

A few concerns:

* As developers, our 'world' is so defined by text, we textify things that aren't: We write marked up documentation in plain text (HTML, markdown, etc) and we despise using tools like LibreOffice to write that sort of thing, and we even 'draw' helpful graphs in `.dot` files. We do this for a good reason: It 'works' with our other tools. git itself, and the cavalcade of git-understanding frontend version control systems, are excellent at showing you diffs between textual representations. They don't do 'diffs between these 2 png files' or 'diffs between these two .docx files' well or at all.

Hence, these projects either balloon, or need a pragmatic take. Either you staple 'also reinvent git' onto the project (and in passing you are increasing the hurdle to adopt or try out this stuff for any interested folk), or you think about how to adapt the idea to fit existing practices.

In this specific case the latter seems like the obvious answer: The way to store the program is as a file that, if opened in a text editor, looks just like it. But, I _can_ edit files in git and it looks like a text file even if it really isn't; so what happens if I edit an eyg file with a text editor? How 'perfect' must it be? What happens if in hand-editing the file I added some whitespace that shouldn't have been there as per the canonical storage rule?

These are all easily solvable details, of course. But it's where my brain went. I'm pretty sure the correct answer is 'the source file is still text and is still readable; it's just that the language has some extreme style requirements (think about a language that has no line continuation facilities whatsoever, long lines will just have to be long lines, and dictates exactly how many tabs you can insert; indenting with spaces is not allowed at all, that sort of thing). This is fine because the language is meant to be read as plain text but only edited with the structural editor.

* I often try to think how it would be if I was doing my programming work with a structural editor. From time to time I do things that seem blatantly annoying if I only had a structural editor. Where I really _want_ to dip into syntactically utterly invalid gobbledygook because I'm doing some text edits which will get back to valid code but I go through invalid code. For example, block-based copy/pasting (block = multiselect/multicursor). I'm having a hard time seeing how that would work in a structural editor but I use it from time to time. It feels like a structural editor can hopefully come up with alternatives for all the use cases but I'm not sure. Should there instead be a 'fallback' option where your source file turns into raw text mode and your edit functionality is like any plain jane text editor, you do your text-based transformations and then when done exit that mode, at which point the structural editor reparses what you have. I think that's right but it means the language does, actually, need all the bells and whistles after all: A Parser, an AST, good error handling for syntax errors, and so forth.

The author appears to be unfindable, the abstract is clearly talking about something close to this but also mentions adapting existing UK based fossil fuel powerplants, lowballs a bunch of estimates, and somehow brings up a seemingly completely unrelated process that is also well-trodden ground in the distant past but hasn't been used in a century: A way to take the MnCl2 (Manganese-chloride) that is the waste product of an old timey way to make chlorine gas, and get yourself the manganese back out so you can recycle the process.

Which flummoxes me because the castner process was the one that _does not_ involve any chlorine. Perhaps the author of this paper is referring to the general principle here, which again is a mystery to me because the castner cycle I am referring to (sodium as an energy transport; [sodium + water] -> [heat, h2, caustic soda] to 'consume' it, [caustic soda + energy -> water, sodium] to produce it) doesn't have waste product at all other than water.

How did you find this? It's.. fascinating.

Yup. And deserts are pretty good places to build massive solar farms.

The more mainstream way of thinking is to electrolyze water into hydrogen and oxygen. Which requires pure water (extremely pure; trying to electrolyze water is difficult and corrodes the anodes and such as is; doing it with salt water? Currently, disastrous, and I believe tons of money is being thrown at that problem with so far no satisfactory results). That means you waste a bunch of your energy on a desal plant just to get clean water out in your desert, and this gets you an ecological disaster as the briny mess (a desal plant converts energy and salt water into plain water... and a boatload of very highly concentrated salt water of course. As the dead sea and such can attest, that stuff pretty much kills an ecosystem, whereever you care to dump it).

I did some math and it's not that much water. But, hey, _its water_. It's more than enough to provide free and plenty water to the few people that live in these places. It's not enough to start farming alfalfa or whatever, though.

I'm glad sodium is having its day in this configuration of using them in batteries.

What I'm really trying to understand is how in the blazes we aren't using Sodium _directly_ as energy transport mechanism.

Using the Castner Process ( https://en.wikipedia.org/wiki/Castner_process ) you run the process of (caustic soda + energy) -> (water, oxygen, pure Sodium).

This process is 'perfect' in that you don't get contaminants; you lose nothing in this reaction. (It's decidedly imperfect in that the reverse reaction occurs during, so H2 wafts off, and it needs ~330ºC to run).

This process has been done to death in the early 1900s, but humanity hasn't done this stuff for a 100 years since the invention of a different process that turns NaCl into Sodium and Chlorine gas, because the latter is _also_ valuable, whereas water aint.

It's... perfect. You ship caustic soda which is relative to other energy processes and carriers not all that dangerous (you don't need to store it pressured for example), cheap, extremely abundant to the desert, there you have a massive solar farm that turns into pure clean water and pure Sodium. That's even better than a hypothetical amazing Electrolyzer, because you _need_ water with those, whereas castner _makes_ water. I hear they can use that in the desert. Oh, and the anodes can be made from iron, which is cheap, easy, and abundant. Unlike the material you need to make your anodes from in state of the art water-to-H2 electrolysers!

Ship the sodium back. All you need is clean water. Toss a bucket of water at it and it poofs back into (Heat + H2 + caustic soda). Again, __perfectly__, no losses. You don't need a reactor or a catalyst or pressure; that process just goes automatically, all you need is a bucket and a vessel.

Storing sodium is, despite the youtube movies, easy. Some paper steeped in oil is all you need to wrap it in. It's stable under all 'warehouse temperatures' (-10 to +70), does not need pressure, and __has zero losses during storage__. It's also quite light.

Some back of the envelope math says that it's energy dense enough; a containership full of sodium contains more than enough energy to pay for the trip and then some - about as much H2 you can make with that as a ship with pressurized H2.

I'm guessing I must have messed up that math because this feels like it solves.. everything. Free energy for all. There's enough Sodium the world over, you can start right now (Sodium is already made in industrial quantities for other purposes, so you can just buy a containership's worth right away). Surely after 100 years of science we can improve on the already functional Castner Process. Solar panels are idiotically cheap and plentiful.

You can convert half the sahara, or the entire east coast of Spain, or the sun belt, into a giant solar farm, just ship coastic soda to it and sodium out. More energy than you'll ever need, and you solved the availability problem because you can store it, at no loss at all, effectively forever, at nearly no cost. Any warehouse can be converted into storage for peanuts.

I'd love to know what I'm missing here.

Yes. And one of those vaunted differences between 'senior' and 'medior' is knowing the difference.

Because I can confirm what you said: Both experiences are real.

Brewing it up yourself can blow up in your face.

Reaching for external deps that solve the problem can blow up in your face.

Knowing which choice to make is _tricky_ and is hard to confirm. It doesn't sit well with programmers; either solution will _work_ (you can't write a unit test that 'fails' if you made the wrong choice here), and even if you're willing to accept highly suspect, Goodhart's law-susceptible metrics such as LOC, you still can't get anywhere because it's trading off more code you have to write and maintain without help from a larger community against having fewer lines _in total_ as part of the system.

I do not know of any way to do it right other than to apply a ton of experience. And it's really hard to keep yourself honest. Even if you're willing to wait 5 years and then spend some time looking back, how do you really know?

Anybody with a bunch of experience has seen enough homebrew stuff asplode in their face to be able to paint a picture with how utterly badly that choice could go. If you chose the 'build it on external deps' route you can easily tell yourself you did it right by painting a terrible picture of how it would have gone if you made the other choice.

But the reverse is just as true.

I think I'm really good at it. But, writing about it here, I don't have any real basis to make that claim. I look around at other dev shops that make products of similar complexity and it feels like they need 10x to 100x more resources, have more downtime, and have far larger dev teams. But no doubt bias is creeping in there too, and no 2 software products are 100% comparable in this sense.

I naturally trust homebrewers more because they tend to understand complex technical things better. Someone who can just glue libraries together is lost when I ask them to fire up a debugger and figure out why some interaction is not working. A hopeless NIH sufferer needs to be 'supervised' and their choices about what to write needs to be questioned, but, that's doable with supervision. "Just git gud and be technically proficient" not so much. But then maybe that's bias too - that leads to a codebase that is easier navigated when you're familiar with debuggers and reading code to understand it. Reaching for third party deps a lot leads to a codebase that is easier navigated when you're familiar with docs and tutorials. These are self fulfilling prophecies.

Where on the line are we talking?

It's one thing to say: "In my view, EO Wilson's association with Rushton is defensible and should not be considered a stain on his career".

It's quite another to say: "That, and I believe it so much that I cannot take seriously anybody who disagrees with me on this, I shall call them and their viewpoints names such as 'surreal' and make grandiose claims that their opinion is so ridiculous, it requires a cultural change at this magazine".

The latter is what was said.

I see no conflict between holding both of these ideas:

* EO Wilson's association with Rushton isn't a problem, and it wasn't about him supporting those ideas themselves, it was about supporting the idea of 'let ideas be, do not censor them'.

* Singal is wildly inappropriate with this, and the plan as stated is cancel culture/crazy politication of a magazine.

In:

> "Rushton was a racist, Wilson defended Rushton so he's a racist, Singal defended Wilson so he's a racist"

You've made an evident mistake. It's instead:

> Rushton was a racist, Wilson defended Rushton so he might also be and we should look into that, Singal called that very thought of questioning Wilson's association with Rushton as ridiculous - and THAT means he's a racist'.

Maybe still wrong but not nearly as crazy as you seem to think it is.

The sheer amount of additional benefit means this is a gallingly reductive view of it all.

The subsidy for maintaining car infrastructure is causing _more_ co2 per euro invested, how's that fit into these calculations?

This is so useless, it sounds like propaganda.

Not really. Feels like orders of magnitude less than other companies of similar size. And still feels like that today. However, the fact that this sense of 'we are ALL and thus need not bother with anything but company-internal politics and how we influence the world at large' is missing at Apple is now hurting them: They appear to be pretty brazenly picking fights with governments thinking they are the david, and they.. really, _really_ aren't.

One wonders why.

* Lingering influence of Jobs? Even now? * Their somewhat well known weird corporate structure? * A cultural conviction that they are the underdog, instilled decades ago when Apple was doing badly, a conviction that is cherished with such religious fervour it survives even today when Apple has been top 3 market cap world wide, has reigned the profitability-in-cell-phones charts for over a decade, and in general has a profitability that makes your head spin, it's incomparably large (literally: Compare it to other big corps and it is mind boggling).

I just don't know what it is. I find it remarkable that Apple does _not_ seem like it has had its fair share of political infighting and forgetting to compete. It has had its share of that, sure. But not its fair share. Not even a tenth.

It keeps me busy, this kind of thinking. In a good way - something to mull over.

These massive companies that epically fail to adjust, is it primarily a management style (cliché representation: Private equity takeovers – focus on 'management is a job unto itself, I do not need to know much or care much about what this company actually produces', and perhaps as a consequence, cost cutting over care about the product, and considering the general opinion about your company and products as a 'brand thing that I do not need to care about; I have a marketing department for that who can fix this by tossing some ad euros at something')...

or is it more fundamental, that even with pretty good management, companies inevitably turn into a giant rusty smattering of cogs that generally keeps running but is nearly impossible to reconfigure? That we should e.g. study what Apple is doing with its odd corporate management structure: That it is _exceptional_ for a larger company to be able to pivot quickly regardless of market, circumstance, or management team?

Or is software development just uniquely difficult and therefore it is highly likely that a company that starts with a better-than-average grip on that and worse-than-average everything else still wins over a company that needs to 'buy in' to software?

Not enough data to really know, and the answer probably a convoluted mess of 'a little bit of everything'.

The gist you're trying to convey is fine: Prioritize those things that _directly_ cause meaningful damage to maintainability.

But a code base that is stylistically inconsistent is itself a source of unmaintainability. That's probably a case of "perfection is the enemy of good enough"; a multi-year, multi-member project perhaps cannot reasonably be expected to consistently pick e.g. a list comprehension instead of a for loop under similar circumstances.

However, just stating casually that it is _irrelevant_, or that it is hopeless, feels like giving up a bit too quickly.

One would assume that the cost to morale etc is overblown (if your team treats every comment as a minor 'error' that was caught, or worse, gets defensive about them - yes, _of course_. The solution is to tell the team that a directive suggestion in a code review simply isn't a complaint, error, oversight, or otherwise to be taken as negative feedback in any way. Code review is a process, it has multiple goals). Furthermore, if you spend the time to try it, presumably the team will coalesce, and the frequency of such comments will decrease.

In practice a pointless style fight might break out where one side of the team insists 'situations like these should use for loops, not comprehensions!' and another side vehemently argues for the opposite. At which point, yes, that is obviously an extremely bad outcome. But perhaps _that_ is the right time to throw in the towel and agree together to allow a modicum of personal preference.

Of course, if there are all sorts of maintainability issues, by all means, _do not_ spend much time on fighting such esoteric style battles at all. But not all teams are dysfunctional :)

Isn't "turns out there are _lots_ of look-alikes, often literally pixel-for-pixel identical in most fonts at all sizes, in the unicode tables and that might cause some confusion when parsing text" like.. lesson 101 for unicode?

At any rate, I find the conclusion a bit hilarious: "Ah, the input text uses that symbol that very explicitly DOES NOT MEAN 'minus', it _ONLY_ means hyphen, and would be _the_ unicode solution if for whatever reason you want to render the notion: Hyphen followed by a _positive_ cash amount".. and.. I will completely mess up the whole point and just treat it as a minus sign after all.

What, pray tell, is the point of having all those semantically different but visually identical things in unicode when folks don't even acknowledge that what they are doing is fundamentally at odds with the very text they are reading?

A lot less than what your average 'I just reuse the same password on a million sites' or your average 'my password is "iloveyou8", you see, the 8 makes it secure!"' user gains from 2FA.

But it's not nothing.

If you get phished and enter both your password and TFA in a scam site, they can log in as you, but they will not be able to log in as you later on, and (presumably, if github configured their stuff correctly) them _changing_ your settings (either updating TFA or removing the requirement to use TFA) is either not possible without _another_ attempt to phish you, or will result in you at least knowing e.g. because you receive an email from them. In contrast if they have your password and that's all that is needed to log in, they can now log in as you for however long until you change your password, and you won't know.

Similar benefits apply if your hardware is compromised due to a keylogger. Or, much more plausible, some tool is watching your clipboard. Which _will_ see the password, but _will not_ see your TFA unless you're also copy pasting that on the same device.

If the device that stores your generated passwords is itself compromised and you store your 2FA stuff elsewhere (a good general principle!) then it helps _quite a lot_. Trying to 'fake it' without 2FA is quite complicated; you'd need to store half of your password on one password vault and the other half on another and combine them by hand.

It depends a bit on your theory about how security is best done. if you ascribe to the swiss cheese model (where you layer quite a few slices of swiss cheese on top of each other with the aim that whilst each slice has holes, the stack does not have any holes), then these are quite a few added slices.

That seems unnecessarily harsh.

I don't think that's the gist of the article, but the throwaway suggestion of 'just make lots of copies, who cares about diskspace' is insufficient and thus distracts. It's.. a single line about solutions in an article that isn't _about_ solving problems, it's about highlighting a problem exists and that it's worth solving.

I read the article more as: There is __often__ no good reason to use argv[0], and it should be avoided if at all possible, and if it cannot be avoided, it would behoove the industry to work on ways to make sure in the future it can be avoidable.

For example, why in the blazes does windows taskman.exe list argv[0] in the GUI table view? That's just asking for trouble. Show the actual file path, and always an absolute one - that way you avoid confusion about which executable you're actually running, and it's just as readable if not more readable for every app _except_ those who care about argv[0], e.g. if you ran `/bin/dd` and it's actually busybox, in taskman you'd see `/bin/busybox` instead which'd be worse than seeing 'dd'. That is simple enough to solve (add an API call to update _your own process name_ or at least update your own process 'title' which interfaces like ps/taskman can use accordingly), but, now we're talking about coordinating between OS, glibc, busybox, and so on - lots of parties. I don't mind that the article doesn't delve that deep, as that wasn't the point of it. The point is simply to show the problems the kludge of 'we will show argv[0] instead of the executable name' causes.

This article feels more about explaining that in the distant past, a mistake was made with some history as to why that mistake was made and the deleterious practical effects that this mistake is causing or is likely to cause (most of them security related). It's not really about solving the problem; that presumably comes later and should be sketched out by those who are knowledgable on _that_ subject. That doesn't imply the author is ignorant or that the article is insufficiently defended. Just that it hasn't covered all aspects of what it's writing about.

The post just skips over _why_. It states that Python is 'more modern' than java as an axiom. This is not a particularly easily adopted axiom. For example, python is in fact older than java. Which surely isn't what the author is talking about.

But what _is_ the author talking about? It just isn't said. It merely states that the argument 'python is slow' is no longer relevant. It doesn't even state a reverse argument (why python would be better than java), and thus doesn't even begin to allow waylaying _those_.

As a trivial example, perhaps the author means: A nominally, strongly, explicitly typed languages is obsolete. In which case - how does that explain how, for example, typescript has happened, which actively _re-introduces_ these aspects to a language?

Clearly then, 'python is superior' cannot be taken as a truth universally held and requiring no logical argument.

The rest, sure, whatever - "Programming language used has a significant impact on what you can write and how one would write it" is.. kinda obvious, no? Turing machine logic says that it is _literally_ incorrect (anything you can compute in one, you can compute in the other), but that _is_ something all those with a modicum of programming experience probably take for granted. You _can_ write a compiler in brainfuck, but, that'd be insane.

The tricky argument isn't stated, the obvious arguments are.

I surely must be missing the point of this post.

Also note that 'are these 2 words case insensitively equal' is impossible without knowing what locale rules to apply. And given that people's personal names tend to have the property that any locale rules that must be applied are _the locale that their name originates from_, and that no repository of names I am aware of stores locale along with the name, that means what you want, is impossible.

In line with case insensitivity, do you think `müller` and `muller` should boil down to for example the same username for login purposes?

That's... tricky. In german, the standard way to transliterate names to strict ASCII would be to turn `müller` into `mueller`. In swiss german that is in fact mandatory. Nobody in switserland is named `müller` but you'll find loads of `mueller`s. Except.. there _are_ `müller` in switzerland - probably german citizens living ther.

So, just normalize `ü` to `ue`, easy, right? Except that one doesn't reverse all that well, but that's probably allright. But - no. In other locales, the asciification of `ü` is not `ue`. For example, `Sjögren` is swedish and that transliterates to `sjogren`, not `sjoegren`.

Bringing it back to casing: Given the string `IJSSELMEER`, if I want to title case that, the correct output is presumably `IJsselmeer`. Yes, that's an intentional capital I capital J. Because it's a dutch word and that's how it goes. In an optimal world, there is a separate unicode glyph for the dutch IJ as a single letter so we can stick with the simple rule of 'to title case a string, upper case the first glyph and lowercase all others, until you see a space glyph, in which case, uppercase the next'. But the dutch were using computers fairly early on and went with using the I and the J (plain ascii) for this stuff.

And then we get into well trodden ground: In turkish, there is both a dotted and a dotless i. For... reasons they use plain jane ascii `i` for lowercase dotted i and plain jane ascii `I` for uppercase dotless I. But they have fancy non-ascii unicode glyphs for 'dotted capital I' and 'dotless lowercase i'.

So, __in turkish__, `IZMIR` is not case-insensitive equal to `izmir`. Instead, `İZMIR` and `izmir` are equal.

I don't know how to solve this without either bringing in hard AI (as in, a system that recognizes 'müller' as a common german surname and treats it as equal to 'mueller', but it would not treat `xyzmü` equal to `xyzmue` - and treats IZMIR as not equal to izmir, because it recognizes it as the name of a major turkish city and thus applies turkish locale rules), or decreeing to the internet: "get lost with your fancypants non-US/UKian weird word stuff. Fix your language or something" - which, well, most cultures aren't going to like.

'files are case insensitive' sidesteps alllllll of this.

How hard is this to exploit in practice? Very - this is a silly update in OpenJDK's war against things like Project Lombok.

It _seems_ easy to exploit: Just.. get any jar file containing an annotation processor on the classpath and it will be executed as part of `javac` - and almost every java build tool calls javac under the hood.

However, this is misleading: _if_ somebody with malicious intent manages to either sneak a jar file into the build dependencies somehow, or manages to libxz-style take control of a commonly used dependency, the damage is done. That jar will also be on the classpath when running the app. So now we're running compromised code. Java is not a sandboxed thing, running malicious code inside a JVM is a bit like an XSS web attack: The game is lost. Totally and utterly.

The fact that javac runs annotation processors by default until JDK23 does mean that a compromised build chain now runs _during the build_, whereas starting with JDK23 they'll only run when you run the app.

This doesn't seem impactful to me; I'm having a hard time figuring out scenarios where this is meaningfully less bad. Developers tend to run the app they are writing. The odds a developer will build a source tree and never actually run what they built, seems insufficient to consider this a meaningful contribution to security.

CI servers might be a useful place to look for 'systems that will run the build but will not run the app', except - no. Just about every CI tool will run some tests, thus, running the app, thus, running the malicious code.

Which gets us back to: OpenJDK's backwards-compatibility breaking crusade. The OpenJDK team has also broken reflection (you can no longer access anything in another module that wasn't explicitly exported without command line switches, even though reflection used to be able to do this. Reflection has 'CARE! You are accessing APis that were not designed to be messed with!' written on the tin. It's.. the point of it). - same reasoning. "For security" without being particularly clear about how that update contributes to security. It's not about 'it is impossible to use reflection to cause serious damage' (it is very possible to do that, in fact). It's more about: .... if you are running malicious code inside a JVM, we've got much, much bigger problems.

It's sort of like stating that security is improved by ensuring that it is no longer possible to open the front door from inside the house without a key. Seems nice - but, they're... already inside the house.

What if the common trend of 'house prices rising totally out of whack' amongst various locales (Canada, USA, Europe, Australia, China) is not.. actually, a common trend? No single explanation suffices; it's just coincidence.

Low interest rates raise house prices. This has to be a 'duh' thing, really, but, governments don't really appear to 'get it', or, play dumb for political reasons. If, after adjusting for inflation and the like, the exact same house costs €500,000 in 1980 but costs €1,000,000 in 2024, BUT, interest rates in 1980 are double what they are in 2024, your mortgage cost to buy that house is __pretty much identical__.

It's oversimplified to say that this means 'real house price has not changed'. It still takes more money to actually buy that house. But, of the money you pay every month for your house, more of it is a weird, not very liquid investment portfolio, and less of it a weird form of rent. It's got all sorts of problems: Not everybody qualifies for a mortgage in the first place, for starters. But _in the end the amount of money you have to burn just to live in a house is identical in this hypothetical scenario_.

One lesson you could learn from it is that everybody is whining and houses are just as affordable as they've always been, but that's not my point, and isn't really true. The point is more: With low interest rates, house prices skyrocket.

This explains _some_ high house prices, but certainly not all.

For example, China's is an utterly different explanation. Due to the way their government is set up, the usual benefits of a free market, namely that the population 'intelligence of the masses' their way to efficient allocation of resources isn't a thing china 'does', in essence. Government decides what happens. And so far, they've decided to build more houses than there will ever be chinese people to live in them. Ever. This is a bit of a problem today and will be far more of a problem tomorrow. But that's it. That's the simple, sufficient, and therefore only required explanation. It has NOTHING to do with how hard to it is to build in China (it is not), nor with population growth (it doesn't, or rather, a sheer and severe drop in house prices looming, that'll be explained by China's population glut). It's just that: They built way too many, and their market system cannot respond in kind to stop that runaway process.

In europe, yes, in large part runaway NIMBYism and being at the forefront of ecological change, putting limits on how much nitrogen/co2 can be 'used up', and building does take quite a bit of that - has put the breaks on building. Especially combined with extremely low unemployment which hurts the building sector. "Too few houses being built" is a factor.

But not the only one. And I think, not even the largest one.

Yet another explanation is lack of efficiency: Fewer people partner up, so, more people live alone. They tend to use space inefficiently: They all want their own kitchen, their own shower, their own living room, their own bed room, their own hallway, and so on. A really cheap and ludicrously efficient solution to _that_ is dorm-style living together. Instead of having a small crappy single-tenant kitchen, why not have a giant luxurious very well stocked kitchen you share with 9 other solo tenants? Yes, there are all sorts of downsides to this (which lout has made a mess of the kitchen?!? - and nobody wants to deal with a cleaning schedule), but in the end it is vastly more efficient, and better for social cohesion.

Society in e.g. europe and the US has not, yet, adapted to it. I hope it will. It'll solve the unaffordability of housing crisis all on its own if society wants to invest in it.

Here's a thing governments should say a lot more - a combination of being humble and also instilling humbleness in companies that need to hear it:

"Look mates, if you don't clean up your stuff, we're gonna have to write a bunch of laws and nobody wants that, so, fix your problems". (i.e: Government is aware legislating something probably results in a highly suboptimal/inefficient endresult, but, it's the only tool governments have. It's just as much on a company / on all companies in a given area of expertise that government sees no way out other than to wield the heavy and inaccurate club of law-making).

Separate from the many comments that highlight both how [A] the GDPR is a lot more than those cookie banners and [B] those cookie banners are like those email footers - lawyers gone nuts. A whole bunch of them are not required as per GDPR, just there because someone asked a lawyer and of course they say 'yeah sure add it'. If I ask a painter if it's a good idea to paint my house at this point in time, they're bound to say 'yes':

Companies went way too far with it, so GDPR happened. It's a good thing to teach companies that going too far results in annoying laws. It's fine even if the GDPR is a loser - if everybody loses, that's.. sad, and a better law would be much preferred, but that can still be better than no laws, because its mere existence tells companies to try not to go too far.

So far, US-based companies do not appear to have understood this (see also: USB-C rules, apple's current problems, repeated and widespread illegal shit going on at banking institutions), but it's worth doubling down on it until they do.

Tesla was in a ridiculous bind.

Its market cap was about 4 to 5x higher than any other car company. That kind of difference is hard to justify based on tangibles such as 'well, their brand has more value' or 'well, they are just.. better at building cars than their competitors'. Sure, but, 5x with no way that other companies can catch up in the next 10 to 15 years?

Instead, it 'worked' by peddling itself as tech company that so happens to make cars.

The problem is, that veneer requires upkeep. Specifically, actually selling to the masses requires being competitive with them, but, lowering prices and acting like a car company would thus starts eating away at the idea that Tesla is a tech company and not a car company.

Screwed if you do, screwed if you don't. Because the car companies have 'caught up' and are now making all-electric sedans with tech integration. And the car industry is trying to squeeze out the all-electric sedan with cheaper hybrids. Tesla can no longer rely on 'sports brand uniqueness' (that market is no longer solely tesla's, and it is far too slow for tesla's current valuation).

I have no idea how to solve for that. I'm assuming tesla's stock is on its way to be ~25% of what it is now.

I find this the most plausible explanation by far:

* The highly professional outfit simply did not see teknoraver's commit to remove liblzma as standard dependency of systemd build scripts coming.

* The race was on between their compromised code and that commit. They had to win it, with as large a window as possible.

* This caused the amateuristic aspects: Haste.

* The performance regression is __not__ big. It's lucky Andres caught it at all. It's also not necessarily all that simple to remove it. It's not simply a bug in a loop or some such. If I was the xz team I'd have enough faith in all the work that was done to give it high odds that they'd get there before discovery. That they'd have time; months, even.

* The payload of the 'hack' contains fairly easy ways for the xz hackers to update the payload. They actually used it to remove a real issue where their hackery causes issues with valgrind that might lead to discovering it, and they also used it to release 5.6.1 which rewrites significant chunks; I've as yet not read, nor know of any analysis, as to why they changed so much. Point is, it's reasonable to think they had months, and therefore, months to find and fix issues that risk discovery.

* I really can't spell this out enough: WE GOT REALLY LUCKY / ANDRES GOT LUCKY. 9 times out of 10 this wouldn't have been found in time.

Extra info for those who don't know:

https://github.com/systemd/systemd/commit/3fc72d54132151c131...

That's a commit that changes how liblzma is a dependency of systemd. Not because the author of this commit knew anything was wrong with it. But, pretty much entirely by accident (although removing deps was part of the point of that commit), almost entirely eliminates the value of all those 2 years of hard work.

And that was with the finish line in sight for the xz hackers: On 24 feb 2024, the xz hackers release liblzma 5.6.0 which is the first fully operational compromised version. __12 days later systemd merges a commit that means it won't work__.

So now the race is on. Can they get 5.6.0 integrated into stable releases of major OSes _before_ teknoraver's commit that removes liblzma's status as direct dep of systemd?

I find it plausible that they knew about teknoraver's commit _just before_ Feb 24th 2024 (when liblzma v5.6.0 was released, the first backdoored release), and rushed to release ASAP, before doing the testing you describe. Buoyed by their efforts to add ways to update the payload which they indeed used - March 8th (after teknoraver's commit was accepted) it was used to fix the valgrind issue.

So, no, I don't find this weird, and I don't think the amateurish aspects should be taken as some sort of indication that parts of the outfit were amateuristic. As long as it's plausible that the amateuristic aspects were simply due to time pressure, it sounds like a really bad idea to make assumptions in this regard.

Not the CO2 - the C. Technically you don't need the Cs at all, you can just burn H2. However, H2 has all sorts of annoyances; running a car on H2 is difficult. Running a boat on it, not really feasible right now.

Your worry about the 'gap' is sensible but (probably) not relevant here.

You're asking to do the job of 'produce energy in a sustainable way' and the job of 'use said sustainably produced energy efficiently' in tandem, never raising one without also raising the other on the same day.

Not. Possible. This market is already far too complicated. So, instead, you work on one of the 2 edges and trust that the market will fix the other edge. If not immediately, then at least create a stable incentive.

For example, right now, solar and wind is generally considered 'cheapest', but that glosses over an important detail: When the sun is out and it's windy, power prices are often __negative__ for it. So cheap, it's negative. That's because so much solar and wind is produced, the demand side hasn't caught up. Power MUST be used IMMEDIATELY, you can't just 'let it go round and round on the power cables', they'd just asplode. If there's a sudden unplanned influx of power then that's bad and thus you get money _back_ if you take more power off the grid in that time. And, the flipside: ON a misty day (no wind, no sun), power is very expensive. Because supply is lower than expected. (Prices go negative because not all solar/wind systems are smart gridded up; if they were, they'd just turn themselves off and stop producing. Which merely reduces the price to 0 instead of negative).

Hence, one of the big missing links in this future renewable energy world we're trying to make happen, is an energy _demand_ that can react perfectly to the inherently fluctuating nature of energy _supply_ where the supply is based on solar/wind.

One solution is to add a really stable or flexible source on the supply side. This is partly why richer countries still are building gas-based fossil fuel powerplants: Gas plants are easily 'tunable' - you can pretty much just rotate a volume knob and the power output responds pretty quickly. Coal is harder to 'tune', and nuclear is MUCH harder to tune (twiddle the knob now, it has an effect hours from now). Regardless of the tuning, a fossil fuel powerplant, even one that is usually running at nearly zero flow, is something we'd prefer to avoid.

So, a better solution is to instead have flexible demand that can respond to fluctuating supply. But that's really hard to do!

The solution so far is to let the grid mediate: Folks producing power just shove it on the grid, prices respond to supply, and the hope is that the cheap (or even negative!) arbitrary price drops incentivize the market to come up with ways to use the free power when its there.

This is sort of working but the biggest issue is the grid part. It's actually really pricey to build a grid that can deal with massive spikes, and the exact places where you want to build wind and solar (far away where there's plenty of space) is where there is no grid. Because nobody lives there.

Methanol offers an enticing way out. Instead of building, say, a wind farm in an urban area (complicated), or a wind farm where there's plenty of space (but no grid connection that can deal with it), you build a wind farm out of the way and hook it up to a methanol factory. You just store the methanol (it's easy to store - liquid and not all that poisonous or volatile), you can even pump it, you can ship it.

The amount of research and money flowing into this model of 'make fluctuating renewable energy sources and hook em up to methanol producing things built right next to them' is limited because the demand for it isn't all that high. But it's not all that technically challenging (within reason. My point is, this is WAAY easier than nuclear fusion, for example) - so, create stable demand for it and it's highly likely the market will provide.

Hence, it's oversimplified but in broad strokes fair to call methanol 'low emission' even if methanol supply today isn't great.

Many java editors (notably, eclipse) work the same way, _if_ you configure them to do so_: Just run it, don't worry about the compilation errors. If the code never hits that segment (in java, if there's a syntactical error in source code, that entire class cannot be used, but if it's a semantic error (e.g. a reference to a function that doesn't exist, which is syntactically perfectly valid, that's a semantic error), only that method is 'tainted'. If you hit a tainted area the debugger kicks in, freezes the process, and breakpoints on the spot. You can then fix it if you want and continue, or inspect the stack and state of e.g. local vars and learn something.

What I find surprising is how few programmers I talk to are aware of this, let alone use it. I find it a significant productivity boost.

Extrapolating away from debuggers: Everything should be warning, nothing should be an error. Then adopt a policy that you don't check in warnings. I find it utterly insane that 'unused variable' is treated as an _error_ (in the sense that it prevents compilation). It.. just isn't.

I hear _lots_ of noise in the line of 'well but my dev team will just ignore that rule', but that's a "doctor it hurts when I press here" issue. You don't solve that by just being more beliggerent, you fix that by having a chat with the team.

I wonder what 'friendly' means in the context of 'a programming language', but if its: "Assuming you are not a complete idiot", that's a plus, I guess.

I assume in the smallprint when you got 23andMe to do a DNA analysis of you, it said that you give them the right to do this.

One of those times where reading that small print realllllllllly was important. And anybody who signed it presumably didn't actually understand what they were signing away there.

I'm not a lawyer, but if I'm 23andMe, and I get sued in the USA that there was no actual meeting of the minds here, and that they don't really have consent regardless of that smallprint, I'd not be all too confident I'd win that case (I wouldn't be confident it's a total loser of a case either; the users _did_ sign, after all).

Same situation in the EU and I'd be even less confident.

Hypothetically pushed scenario: A smallprint / clickthrough / 'you accept by tearing this sticker' style licenses dictate you owe them $100000 and a kidney if you fail to review the product with the maximum possible score within 1 month of purchasing the product.

You tear that sticker and fail to review in time. They come a-knockin, scalpel at the ready. There's zero chance you lose in court. That's not something you get to stick in a clickthrough contract. No meeting of the minds would be the legal basis.

Hence why I wonder: Will 'you signed away your rights; we now get to sell your DNA profile' actually hold up?

It's not of course. But 'screening' news casts for 'inappropriate' content is easy and it is easy to point fingers when it doesn't meet 'standards'.

Whereas with wikipedia, unless a dedicated team of editors who are contracted or liable to vet _every_ change. Possibly only for the UK, who get a special 'only with vetted edits' version or some such, I don't think wikipedia would be interested in making such a thing.

Separate from that, wikipedia has various pages on (conditions related to) our sexual organs, as well as lots of articles about politically contentious things. I don't think they are particularly interested in filtering that either.

In contrast to news channels, most of which would have no particular complaints about a bunch of rules about content. As a rule your 9'o clock news isn't going to just casually show frontal nudity (except e.g. Germany because they're fine with it).

One obvious problem is all those words in single quotes: Who gets to decide? Evidently you aren't happy with whomever decided how far you can go with the content shown on the news, and I concur that it goes quite far. But the point isn't about the current standards being applied. The point is whether _any_ standard can be applied at all.

To news: Yes. To wikipedia: Not in a way wiki foundation would accept.