xorcist

Stocks are valued against the risk free interest, or so the saying goes.

Doubling interest rate from .1% to .2% does a lot for your DCF models, and in this case we went from zero (or in some cases negative) to several percentage units. Of course stock prices tanked. That's what any schoolbook will tell you, and that's what any investor will expect.

Companies thus have to start turning dials and adjust parameters to make number go up again.

They are self driving the same way a tram or subway can be self driving. They traffic a tightly bounded designated area. They're not competing with human drivers. Still a marvel of human engineering, just quite expensive compared with other forms of public transport. It just doesn't compete in the same space and likely never will.

People sometimes conveniently forgets that inflation historically has taken some 12-24 months to trickle through the economic system. That was the case this time, too. And the first inflationary impulses, famous for being "transitory", was actually before the Russian invasion of Eastern Europe.

> because he simply thought he could run a lot leaner

Because he suddenly had to pay interest on that gigantic loan he (and his business associates) took to buy Twitter.

It may not be the only reason for everything that happened, but it sure is simple and has some very good explanatory powers.

While the general idea is right, maybe it's not the best example. Elastic did contribute quite a bit of code to Lucene to the point where it almost looked like a project of Elastic NV. It seems however the Apache Lucene project managed to stay untainted by it and is by any measure a very healthy and functioning open source project.

Good question and one that bears repeating. Because if you desire the aspect of free software or open source that is a level playing field, where no vendor has any special status or secret sauce, which in turn is what enables vendors to submit new features to a multi vendor codebase instead of maintaining private branches.

We learned this from X11 and the Unix wars, and history repeats itself in the countless free-core-but-proprietary-enterprise-features projects that never really expand beyond their parent corporation.

This is why trillion dollar corporations must not have special rules and the playing field must be even to any use, despite how unintuitive it may feel. Someone tried to codify it early as the first of the four software freedoms (the keyword being "anyone").

That has been tried before. What happens is that people choose the school where there is easiest to get good grades. Fast forward a generation or two and there is a race to the bottom, schools take their mission to prepare for standardized testing seriously at the expense of learning. Over time, our outcome will depend on what you measure.

School systems are also special because you don't really want to overprovision school seats, so if there at the end of the day are as many seats as there are pupils in the system as a whole, there can only be selection and never competition in the economic sense.

acme.sh is 8000 lines, still a magnitude better than certbot for something security-critical, but not great.

tiny-acme.py is 200 lines, easy to audit and incorporate parts into your own infrastructure. It works well for the tiny work it does but it does support anything more modern.

These types of statements are hard to take seriously. Those tools are remarkably good for what they are, and the fact that they can help me understand texts in foreign languages is amazing. But indistinguishable from a professional native translator (which I take it you mean, being a language native is not enough to be a translator) is something else entirely.

If you really believe that, why not recruit a professional, do a blinded study, and if it's really industinguishable you can probably get a nice publication somewhere. AI companies are flush with cash and will not think twice about sponsoring such a study.

If your product is a strong brand then that would make total sense.

I believe the main criticism against Signal is that they should focus on getting widespread traction of secure messaging, and that perhaps the brand can be a relatively distant concern.

Much more importantly: Never ever auto-translate content to the user's language.

Present what languages you actually have the data in. The user is smart enough to click the "translate" button in the web browser should they want. That translation is also likely to be better quality.

English is not my first language. Or my second. But I understand it well enough to work in it every day. And I never ever want to wade through auto-translated garbage just to find the right button to read the original English version. Because for some reason this is only a problem for English, web sites using other locales never do it, which should be indication enough that international visitors hate it.

If you ever think about using machine translation tools for you web site, first you must do a full translation round trip for every language before publishing. Translate, paste back the result and translate back. That is roughly what you intended to publish. Don't do it.

Printing out the QR code and giving out to all your friends?

I think most QR systems include some sort of rolling timestamp to combat that.

That sounds like a sure way to ensure they don't get the info, buried as a bullet point among thousands (in a pdf).

FTP can absolutely be secure. But it doesn't need to be if the transferred data is.

These links tend to be important, and it's not uncommon to see both rented wavelengths and VPNs being used. And out of band key exchanges.

No knowledge about this specific situation however.

It wasn't always that clear who the members were. Demos and cracks across several machine types were handled by separate people who didn't always know each other.

Especially Fairlight was a pretty loose group which many people were sort of affiliated with, and sometimes would release stuff under that name, and nobody really knew if they were officially members or not. There was a bit of drama as everyone didn't always get along.

> "We spent x weeks working so users with low memory space can update"

But it's the other way around! That's the whole point. Every app starts out small. Apps don't grow unless you add complexity to them. It's much less work to do something simple than doing it overly complex. We see this all the time.

The question to ask should instead be: How can it be that "We spent x weeks working on increasing complexity" is not completely unsellable, if all your users want to do is pay their bills?

Now, reality is never that simple and users constantly ask for new features, that much is true. But why can we as an industry never listen to all those users who don't want new features?

It used to be completely normal to identify a need, sketch out the most appropriate funcitonality to solve that need, and them implement it. Then the core functionality is done. The software can continue to be developed around that functionality, but the core is fixed because the problem domain is well described.

No software is allowed to fit the problem domain anymore. It's just a constant pile of features upon features, to keep a legion of product designers, user experience managers, product owners, and an army of developers busy every day with no end in sight. The only break from the treadmill is the occasional product redesign, and if you can't afford that this increment then you can always change the frontend framework. Whatever happened to decent problem modelling and when you're done, you're done? Optimizing what we got instead of expanding it?

Hence "Western". Makes sense. Same reason why Europe is doomed and the US will flourish. It's never that simple though, is it? There are numerous counter examples all thoughout history.

That's exactly my point. Users expect desktop software to read their home directory, which is an artefact of running under the same uid. The same can not be said for server software, where the expectation is different.

Linux desktop environments had the chance to set a precedent here where software could for example have had a directory named after the application under the user's home, and use subuid to access files. That is simply an example, but would be a backwards compatible way to create a shared culture how Linux desktop software operate, and easen a transition where desktop software could be limited to "their" own directory.

Instead they squandered this chance by focusing all effort on moving dotfiles around (.config was such a waste of energy where we the heated debate could have been about something more useful, such as the above). Now we have Snap and Flatpak which both try to solve a culture problem (where we store our files) with technical solutions (bind mounts! modal gui:s! popup dialogs!). These will not improve the situation. In the best case it will train users to click "Yes" more, which we know not to help security.

> They're exploiting a bug in Western civilization,

Who are? Did he say?

Sorry for not listening through the whole thing. There's a lot of pointless rambling going, which I guess is something inherent to the format more than it is to him.

To what extent has those findings been verified? I know the was a lot of noise about things that turned out to be mostly imaginary.

Absolutely, I just suspect that wasn't a realistic option at the time. It is obvious a keg of beer has not gone flat but it's probably not as obvious when buying a keg of boiled water (if that even was a thing back then).

Server software is usually compartmentalized in uid:s but desktop software seldom is, if ever. Package managers and maintainers could do a lot here to make it easier. Some things long time Linux users like to do, like running Firefox as a separate user, is still a much more involved process than it should be.

A lot of it is probably standards and culture work, like where a user can expect to store files and have them readable by Firefox in this example. So perhaps this is something the GNOME/Freedesktop people could have been interested in and made a difference? Instead we have things like Flatpak, which is good but not the lowest hanging fruit here.

That's why it's kept sealed, under pressure. I wouldn't fill a water bottle and let it sit for many months before drinking it ever today. A beer bottle with CO2 atmosphere can sit for a long time.

There may be other reasons to prefer beer where the alcohol is relevant of course, just not for freshness. And freshness could absolutely have been relevant in the choice of drinks to load, together with low cost and acceptance in general.

I have taken part in audits for several organizations over the years, and I can assure you that's not how audits are done at all.

In fact, should the auditor find there is a way for them to access sensitive data without it being logged, they will flag it immediately. That would be the case even under simple financial regulation.

There is absolutely the risk that the people you audit will lie to you or present you with false data. In practice that's not common, because they stand to at the very least lose their jobs. It could also be illegal. Not worth it.

We only hear about the cases where a someone is taking the risk of blowing the whistle, and actually manages to get the story out. Hopefully with enough substance for people to take the information seriously. How many cases that are likely to reach public knowledge is left as an exercise to the reader, as the saying goes.

It's also clearly incompatible with most (all?) modern definitions of democracy.

It's not the alcohol that's supposed to kill bacteria, it's the long boil.

That's a bit anachronistic. Pike was released in 1994, the same year as Perl 5.0 and Python 1.0. Ruby did not exist yet!

Being an offshoot of an existing MUD language it was quite usable even a young language, comparably good performance and a compelling C embedding. History could very well have been different. The 90s was a really good decade for dynamic languages.

There's an obvious risk here, same as with strcpy (no, strncpy.. no, strlcpy... no, strcpy_s) that documentation tends to outlive code, and people keep pasting from tutorails and older code so much that the newer alternatives have a hard time cutting through the noise.

I would argue that as bad as some w3schools tutorials were, and copying from bad Stackoverflow answers, going back to MSA and the free cgi archives of the 90s, the tendency of code snippets to live on forever will only be excarbated by AI-style coding agents.

On the other hand, deprecating existing methods is what languages do to die. And for good reason. I don't think there's an easy answer here. But language is also culture, and shared beliefs about code quality can be a middle route between respecting legacy and building new. If static checking is as easy as a directive such as "use strict" and the idea that checking is good spreads, then consesus can slowly evolve while working code keeps working.

A similar situation to Jobs reciting research on how optimal the one button mouse is. A thought bubble.

Why, we will perhaps never know. But likely they were early and it was deemed too expensive back then, or didn't find a supplier they could work with. Now there's too much prestige in it and they can never back down which would be admitting to a mistake.

It would be one thing if it was a one time event but then they repeated that playbook with the lack of a rain sensor.