jeroenhd

There are other hidden benefits as well. Tax evasion and money laundering become a lot harder in a system that tracks transactions. That can be massive benefit or a dystopian nightmare depending on the people in charge, but for many governments that's something worth throwing money at.

> in almost every devops or CI workflow

But that's the core of the problem, isn't it? People setting up devops environments are the reason these flows are so complicated. You can set up the same flows by having Jenkins call out to Jenkins to trigger chains of jobs that can conditionally fail.

People generally don't do it, because there are better alternatives out there for when you want those types of pipelines (which includes Github Actions and their counterparts). Setting up a four-step build+test+scan+tag+push+deploy pipeline in Jenkins is just as hard as it is with Github, if not harder. [Jenkinsfile](https://www.jenkins.io/doc/book/pipeline/jenkinsfile/) is just YAML with extra parentheses.

The modern YAML files are a simplification of the manual steps required to do it all in tools that predated the YAML files. There's nothing stopping you from having a Github runner configuration that's just a call to a single Docker image containing all the bash/perl/Makefile/Kotlinscript/Go/Ruby/etc. files you want to execute. Or you can forego the Docker part and run code directly inside of the repository, with all the security risks that come with it (not dissimilar to having a fully open Jenkins server).

Complicated YAML is a symptom. It's no better or worse than Bash or TOML or Makefile when you start adding conditional automation and multi-step CI/CD flows.

And in Github that would be something like:

    steps:
    - name: Run jabberwocky
      run: docker run -it public.ecr.aws/carroll/jabberwocky:v2018.3 [etc]

It's non-standard JSON, so you can probably just assume most patsers don't support any given commented parser.

At least XML permitted comments, fhe shift to JSON on everything almost makes me nostalgic.

The things done in yaml today would've been obscure bash oneliners had YAML not existed.

Jenkins still exists and it's no less complicated than Github Actions. The complexity gets hidden in obscure script files, obscure tabbed UI, and remote services for doing things Jenkins itself can't do. Defaulting to system tooling makes it almost impossible to predict what a job will do unless you know exactly how paths and tooling are set up (and what versions they're running).

None of my personal experiences with Jenkins had scripts that ran locally, they all relied on pre-installed software on the server because that was the thing people would do before the great YAMLification. You could copy-paste the Jenkins job, but unless you have Jabberwocky v2018.3 installed in /home/JabberWock/RELEASE, the script will fail.

The entire software development flow has been made incredibly complex by hooking up automations into every nook and cranny.

All of these complications need to be enabled manually, though. If your flow is complicated, you can cut it down to manageable size by doing a few more processes manually.

Luckily, all of the simplication and reproduction steps for Github also apply to Jenkins. Github YAML files are just scripts with different syntax, after all. Just like you can run bash locally, you can run act and reproduce whatever Github trigger you need. From there, you can simplify pipelines, stop curl2bashing "plugins", and so on.

This forum tends to be visited by an intersection of technologists and the VC crowd. The HN algorithm is more open and transparent than Reddit's, but any Reddit-like platform suffers from the whims of the community. Currently, it seems like a disproportionate amount of HN users are hyped up about generative AI compared to people in the real world, so you'll see those whims back in voting and flagging tendencies.

That said, there is also a vocal anti-AI crowd here, or at least there used to be. Most of those people seemed to have left for greener pastures seeing how half the HN front page is "someone made XYZ but now with AI" these days.

There are other places that discuss tech that aren't so focused on making money, and those are probably less biased in favour of the latest AI gadget.

On the other hand, since the day ChatGPT was unleashed upon the general public, you should assume all online interaction is happening through AI and should probably be ignored. The human internet died the day we taught computers how to write a coherent paragraph.

The technical details are on another page: https://alexmorleyfinch.github.io/marlin/history/v1/article/...

Your impressions seem about right, but there are a few control steps it seems.

No, but my ISP's IP range once belonged to a business hoster. Wikipedia blocks my IP for that reason too. I'm guessing it has something to do with that, because I can't find inxi references in my config files.

Hmm, after looking around a bit, it looks like they added it (back) to Firefox for Windows, but not for other desktop platforms. Maybe one day.

What inxi commnd shows a map of pollen concentration, weather alerts, and air quality? How do you generate a graph comparing this year's temperatures to the previous yeas' average climate?

Comparing inxi to Windows Weather is like comparing vi to Autodesk. You can make 3d graphics for sure, but it's not exactly comparable.

When I run inxi -w, I get this:

    Weather:
     Message: Error: Your access to this resource has been blocked. Automated
       requests or excessive use are not permitted. This is clearly stated in
       both the help menu and man page. If you want a CLI weather tool for
       routine use, try wttr.in, or use a weather widget. Remember, you never
       had a "right" to this feature, it was just a little easter egg, mostly
       for sys admins, which has instead been consistently abused. If you want
       to know your local weather, look out your window, there it is.

Looks like something in my powerline config somewhere must be querying too much? I can't find anything on my systems, must be a very old misconfiguration on my end. I still think I prefer the Microsoft tool.

Firefox doesn't support PWAs on desktop and removed their previous self-designed equivalent years ago. It's the reason Brave is still running in the background on my machines.

It depends on the program. Many of them clean up, usually with a little checkbox to confirm throwing away your settings, but a lot don't. It might not be 100% of the apps, or even 50% for that matter, but it happens.

On macOS that mechanism is simply impossible if you install the app using the drag&drop method.

On iOS (and the same OS in other form factors), Safari is tied to your operating system. Unlike Android or Windows or even macOS, your browser cannot be updated when your device no longer gets feature updates.

In the EU one could theoretically deploy an alternative browser engine, but that relies on the version of iOS being recent enough to get the changes that Apple had to make to permit that, and in practice there are no alternative browser engines yet.

Java is absolutely massive for a huge variety of applications, most of them servers and daemons. The most common user-facing Java implementations are probably Android and Minecraft, but behind the scenes it powers everything from blogs to logistics to networking equipment to SIM cards.

Oracle's own OpenJDK is free but they will only let consumers download Java 8 for free, that's why companies like Jetbrains ship JDKs with their products.

Google is in the middle of moving ChromeOS to Android, they're not replacing Android with Fuchsia any time soon.

There's a tiny little arrow in the corner to indicate that it's a shortcut.

But this really confused me when I first started using macOS as well. You're just expected to know that the applications folder in the disk image you just downloaded isn't actually inside of the disk image.

When I first opened a .dmg, I thought the arrow symbolised some kind of progress bar and waited for a moment to let it do its installation. That didn't work, so I copy-pasted the folder into my Applications folder manually. When I later opened a different .dmg that had instructions about how I needed to drag and drop myself, I actually realised what I needed to do.

Windows' CRT setup allows for binary compatibility with older versions. You can go without if you just statically compile the dependencies into your program, but many Windows developers choose to rely on runtime versions which may or may not be shared.

MSI's biggest mistake was probably granting developers the capability of invoking any program they like. The format was originally designed similar to Linux packages. Installation steps were atomic and reversible. If something went wrong (i.e. you ran out of disk space halfway through), the installer can undo every change step by step so you can try again later without overwrite prompts. Unfortunately, adding the ability to call executables means that atomicity is usually lost.

macOS applications seem to just package every single DLL they need inside of their application folder rather than relying on the OS. I'd do the same if I were developing for macOS with how often Apple likes to make breaking changes.

The symlinking trick for .so files often breaks on Linux. Method parameters change, structs get altered, and you can quickly create working-but-unstable versions if you have a different version of the same program. The Windows way, used by Flatpak and Snap, of targetting known-good sets of libraries will work around that. The macOS way (AppImage) also works but doesn't allow for deduplication. It might, if the AppImage would be uncompressed and files would be extent-aligned on a modern file system, but in practice that won't happen.

In theory, Windows and Linux offer the same app installation flow as macOS. AppImage and huge .exe files can be moved around and deleted just as easily. Windows will let you do all kinds of things with desktop.ini, including custom folder backgrounds, and its native .iso support can offer a very similar mount-then-delete flow to .DMG files.

Decent Windows uninstallers have a checkbox for that. Often disabled by default.

It's not universal, but at least it's possible. Not having to hunt down random directories (or buying a program to do it for you) also has advantages to user control.

The app icon approach only give the illusion of control. That may be worth something too, but whether you run a .pkg or a program, the app developer can do whatever they want with the permissions you grant it.

There is an advantage to being able to move a program to any locations and run it from there, and while the same can easily be done on Windows (just make one big .exe!), it's not expected for users to just move install directories around.

That said, programs break the same way: configuration pointing at wrong directories, permissions going wacky, you name it. It just seems to go wrong less often on macOS because of developer expectations.

> Same for uninstalling. Move to Trash and poof, unistalled.

That removes most of the program files, but there is no chance for the program to run any cleanup process in the mean time. Library Support, .cache, and all other kinds of remnants remain and have no way of getting cleaned up without manual user intervention. It's like hunting down broken uninstaller files in Windows 98 all over again.

The places that need cleaning up after uninstalling a program:

    ~/Library/Application Support/
    ~/Library/Preferences/
    ~/Library/Caches/
    ~/Library/LaunchAgents/

Or possibly:

    /Library/Application Support/
    /Library/LaunchDaemons/
    /Library/LaunchAgents/

And possibly others that use UNIX-style .config/.cache rather than the macOS defaults.

I do like the "folder as an executable" approach macOS has, but the way the ecosystem goes about program management isn't great. Storing caches and data inside of the app directory for applications installed to a user folder (not the global Applications folder, which would require administrative permissions) would go a long way. Entries in all the other folders could just be symlinks that don't take up any space after you trash a program.

As for installers, macOS comes with its own native install wizard format, akin to Windows' MSI installers. This seems to be the default way of installing programs that need things like drivers to function correctly.

Some relatively recent emoji might not work in outdated browsers/operating systems. Generally, emoji font are regularly updated, but if you're using the stock browser (or Safari) on an outdated phone, you might not be able to render a lot of these emoji.

Missing emoji should still be copyable though, it just won't look as funny.

Energy efficient Linux is hard. Vendors aren't doing the hard work for anything but Android. So, most hardware won't work (for more than a few hours) using normal Linux.

postmarketOS and other projects are working tirelessly at bringing Linux to phones. SailfishOS too. Plenty of Android apps even run inside these runtimes.

App compatibility relies on apps supporting (very) old Android versions, though. It's also flaky in many areas and with how few Linux phones have decent GPU support, there's also a performance challenge there.

For some apps, running on Linux doesn't work because the app developers chose to only run on Play Certified, original firmware (Play Integrity and friends). Those apps cannot be patched to work right unless they implemented their checks badly.

Lots of laptop vendors do. Very few integrate fingerprint scanners into any kind of secure authentication flow, though. There are decent fingerprint drivers for various brands, but connecting fingerprints to authentication beyond basic login requires manual setup.

You don't actually need biometrics to use key material, that's what (f)TPMs are for. They're not set up to be usable out of the box in any Linux distro I've tried, though.

I sort of get it. Every competitor, except maybe GOG, has come down hard in hyper-capitalist value-extraction mode quickly after pretending to do any good-will. For Valve, being a somewhat decent company is part of their ethos, for their competitors it's a means to an end.

I trust Valve not to screw me over, even though I know they totally could. Their own DRM is pretty weak (just put a modified DLL in the game directory and the game will launch), luckily.

> All I'm saying is it's all digital on the PC side of things, and has been for ages, but we have means of maintaining access to the games we love over here, and it's one of the reasons I've gravitated to the PC for quite a while now.

It all depends on where you buy your games of course; GOG will let you download DRM-free installers, but if Steam goes down, your libraries goes down with it. They have made a vague promise that they would prevent that if the company ever went out of business, but who knows if they will keep that promise.

Guarantees about playability went out the window the day free, easily-obtained updates came out on PC as much as consoles.

At least on the PC side, there's a vibrant piracy community.

> AND people don't use a random site on the internet for such filth

Actually, they do. Small, independent image hosts are great because they don't do any sort of VPN busting or user tracking, so hitting them with a few quick images to share is just as reliable, maybe even more reliable, than dedicated image hosting options.

You should double check your local legislation, and the legislation of the country you're hosting in. There's a chance you're liable for illegal imagery, regardless of whether you put it there or not. Plus, the moment someone puts something malicious on there and the indexers find out, your domain will be reported as dangerous/phishing and become inaccessible to 99% of the internet.

It bodes well for Europeans when the Americans begin their invasion of Denmark, at the very least. Not great for a potential Russia-USA war and Taiwan wouldn't get as much support if the Chinese invade would also be difficult, though.

The title says "virtually all" but the first paragraph says "much". The actual stockpile is probably larger than this news report would make it seem. It would be convenient for Trump and his Russia-loving cronies if it would appear that the USA has no more weapons to support Ukraine with, of course.

Many advanced NATO weapons being difficult to produce and only being available in small quantities is something that has been discussed before, I don't think that's news. The rate at which they're being spammed without much result at Iran is, but that's hardly surprising given the current people in charge.

There are valid edge cases where you want traffic to be encrypted on the internet, but be readable by some intercepting device under your control. Parental control software has done that for decades, and there are (in my opinion misguided) regulations in some sensitive industries that suggest having to store a decrypted traffic log.

Corporate MitM boxes are quite prevalent (they caused 5-10% of TLS 1.3 traffic to get dropped before they changed the protocol to fake TLS 1.2 session resumption) and when it comes to corporate-owned devices, that usually shouldn't pose too much of a privacy/security issue.

These setups were a lot easier back in the day when TLS let you set static keys, but you can still dump TLS key files and/or reject all non-proxied traffic with your MitM proxy if you want to do such a setup. It'll break loads of apps thanks to certificate pinning, but that's probably a good thing for such corporate networks.

I too would much prefer it if Google were to open-source their messaging app and provide a full RCS API to Android users, but that doesn't change the fact that both the protocol and the underlying OS are open, and others can implement them. Google isn't the Linux Foundation, you shouldn't rely on them to release everything open source and ready to use.

The AOSP messaging app is barebones to say the least, and has been abandoned since the day Google announced Google Messages and its predecessors. Back when that app was still relevant, RCS practically didn't exist.

RCS is not as simple as SMS. You need access to the SIP/RTSP/RTP layer to do video calling, for instance. RCS registration is tied directly to IMS registration, it was never designed to have multiple apps use the protocol at the same time; it does support multi-device setups, as long as all partipants run compatible software. Break that, and you break basic message reception.

Skipping features that go beyond basic messaging entirely, you could probably have some limited RCS support if Google were to take care of all of the internals. You would still need someone to do regular maintenance, like updating protocols to support things like gRPC transports (which landed this month), taking care of the end-to-end encryption, and whatever else comes up in the future. End-to-end encryption in RCS has been in the spec for maybe a year and a half, Android 14 and lower would not be able to use it at all, and Android 15 would miss out on Apple-compatibility as well. Not sure how you would deal with the payment exchange API in such a system, that would need some carrier/bank-run verification scheme.

AOSP's RCS implementation (https://source.android.com/docs/core/connect/ims-single-regi...) was never used by Android's messenger, it only provides very basic functionality: it exists because it has to for basic IMS operations to work, but Google never really bothered with RCS until very recently, long after they stopped maintaining their SMS app.

One could ask the same of other messengers: why can I not access Signal's message database? Why can I not enumerate emails, or query for browsers' search histories? All are built on open technologies, after all.

You can't build a modern messenger equivalent on IRC. You need a new protocol.

"New" is relative of course, XMPP is 27 years old. Still, XMPP lacks official support for something as basic as "I want to log in on a new device and see the old, encrypted messages that are on my other devices".

IRC itself is a reinvention of `talk` and BBSware. For as long as there will be new use cases, there will be new protocols.

Android has an accessible hardware attestation API already (https://developer.android.com/privacy-and-security/security-...). It's what powers the attestation API that GrapheneOS made as an alternative to Play Integrity and friends (demo app: https://github.com/GrapheneOS/Auditor)

It's up to third party app developers to choose what library to use, of course. A court case between the EU and Google isn't going to chance anything about the verification steps apps like Netflix or your bank might use, that will have to be a separate case.