finaard

Problem is that you have a wide range of makes with different syntax. It has gotten better nowadays where GNU make is available pretty much everywhere, but two decades ago you'd have a range of incompatible makes on different UNIX systems, plus a bunch of incompatible makes on Windows as each compiler would come with its own make.

Assuming you can ignore Windows you'd typically end up with two makefiles (Makefile and GNUMakefile) and a bunch of includes sharing code all make variants understand.

> Perhaps it was a good idea 30 years ago when we were actually building for dozens of 'unstable' variants of UNIX with a dozen compilers

It wasn't. Back then what was typically getting in your way for porting a piece of software was autotools - and fixing it was typically significantly more complicated than adjusting a well written Makefile would've been. My hate for that autocrap mainly comes from that period.

I recently got a m3 macbook pro (mainly because the general notebook market has been shit for a decade now, I needed to replace my more than a decade old one, and there's pretty much nothing apart from apple which is relatively small, has long battery life, a shitload of RAM and a powerful CPU).

Once there's Linux support for M3 I'll probably switch (have an M1 macbook air with Linux which is doing well) - until then I got things close enough to my Linux Hyprland setup with yabai that it is relatively painfree to use.

They used to have an auto organize plugin which was doing that very well - but sadly it is no longer maintained (and no longer working on current versions). I did have quite a few things not correctly recognized with Plex which went away after going to Jellyfin and letting auto organize do its thing.

On the plus side, lack of auto organize made me properly setup the complete arr stack, which throws things into correctly named directories, does support batch renaming for existing stuff, and handles a lot of other stuff on top of that.

A lot of the office stuff can be handled by templates that allow only editing relevant parts - there's not really a need for majority of office workers to have access (and needing to know) all the features of an Office suite.

Over two decades ago I was tasked doing a pilot with IBMs Document Connect for Lotus Notes - it was clear that it pretty much was an Alpha they've been selling us, but it was showing promise. In the end it went nowhere, probably because not too many other companies were interested in trying out a different approach at handling their documents.

We'd usually put the tests in a subpackage so it can be installed and run on devices later on.

Unfortunately that's "industry standard" nowadays. I lost count how often I had that discussion over the last two decades.

Just look at stuff like pip, npm or pretty much any "modern" package manager in use by developers - they're all pretty much designed to pull in a shitload of arbitrary unaudited and in some causes unauditable dependencies.

And nobody wants to listen. That's why I prefer to work in heavily regulated areas nowadays - that way I can shorten that discussion with "yeah, but regulatory requirements don't let us do that, sorry"

The absolute basic should be having a local archive of dependencies which at least received a basic sanity check, and updates or additions to that should review changes being added. CI gets access to that cache, but by itself does not have network access to make sure no random crap gets pulled into the build. You'd be surprised how many popular build systems can't do that at all, or only with a lot of workarounds.

It's pretty common to run tests on CI after building to verify your particular setup doesn't break stuff.

Last time we were doing that we were preferring git upstream, though, and generated autocrap as needed - I never liked the idea of release tarballs containing stuff not in git.

Friend used to run his webservers on Amigas about two decades ago, back in a time where the time of hooking up an unpatched Windows system to a 100MBit connection would have it infected before you could start updating it. "Of course the webserver there is horribly insecure, as there haven't been new releases in years, but it's so obscure that none of the exploits work"

To me the article read more that PostgreSQL might have been the better choice from the beginning - but due to lack of experience in the team MongoDB was "good enough" at that point.

> Cloud services are costly but in most cases you'll pay similar cost in terms of time and in some cases lot more if you pick something complex that you don't know about.

Even just something like EC2 instances is costly - and a surprising amount of stuff in the cloud is just containers or EC2 instances, before redundancy even. Adding in specialized services makes things even more costly.

Problem is that nowadays it's hard to find a team that knows how to properly handle hardware - if you manage to get a handful of people that know how to do that cloud is only sensible for very few edge cases.

And as the article states - in many cases you probably don't even need all that fancy from K8s. I can for the cost of using K8s cloud stuff just put a second copy of our hardware in a different DC (or maybe even a third one), and just fail between DCs if needed. Way simpler setup, and excludes a lot of failure cases I'd catch with a K8s setup.

Also: No bootstrapping rustc from source. There are a bunch of projects trying to get that fixed, but currently pretty much everybody relies on binaries coming from upstream. Having a core infrastructure component like nginx rely on a compiler we can't verify would make a supply chain attack against the compiler very attractive.

I had my emacs setup to edit LotusScript (one of the scripting options for Lotus Notes), which is close enough to VB that it could handle the occasional file - this was a new codebase, though, so it made sense to just start with C#.

That was also the project where I tested if git reached the point where you can have "normal" people work with it as well (which worked pretty well). I never accepted any project where they'd have me work with idiotic proprietary source control, unless the project was "migrate away from that".

I've found chatgpt to be pretty good at generating passive agressive responses to emails (at least it was when I've been playing with it a year ago) - maybe just ask it (or llama, that also does it quite well) to draft a reply to you with just the right level of being insulting?

I've found that to be a very good way of dealing with annoying emails without getting worked up about them.

I had a customer request a project that required C# due to a few fancy dependencies they had purchased back in 2008 - which was my first proper contact with .NET. I got frustrated with the Visual Studio UI after a few hours, and switched to editing in Emacs and compiling via CLI tools, only using Visual Studio for editing the project data. It wasn't too complicated to kick cc-mode into behaving somewhat sensibly with C# code.

I've found lsp-mode to troublesome to configure for what it provided, and occasionally getting in the way, so with emacs 29 I just moved to the integrated eglot. Not that I'm using it much, though - I've found it marginally useful for getting used to new languages, but generally prefer to just have full documentation open - once I'm familiar with the code base completion tends to just get in the way, so I often have any form of completion switched off anyway.

We're now at Emacs 29. I've been following the threads stuff back then out of curiosity - but never seen it as game changer, as most of the annoyances where stuff hangs could just be solved by using async methods.

I just went over all my packages - I'm not using a single one which does make use of the threads API. I used to use lsp-mode, which _does_ create a thread in one situation - which also could've been solved by doing async calls.

A lot of the stuff that should've used async, but didn't got fixed, plus there's an external library to move some other stuff along. I've moved gnus (which used to be notorious for blocking everything) into my main emacs process years ago - and last year even tried setting up a new notebook without the local imap, and made it directly go to upstream servers. Turns out, so much improvements landed in the imap code over the years that doing this works so well now that I've dropped the local cache from all my existing systems by now.

> Is piracy easier? Legality aside you need a seed box, membership to specific sites, and VPN. Which can add up to more than $30/month just to download pirated content. Not to mention the time investment in figuring out how to get the movies and tv shows to your family members on all of their devices.

This part is trivial nowadays: sonarr/radarr and related handle discovery and library management, and jellyfin does the playback.

Reasons I got back into piracy included trying to watch a series with my wife, and finding it gone. Seasons missing while streaming, UI becoming worse (for the last few years of Netflix I fully relied on an external paid service to discover new things on Netflix because of that). More and more content I cared about being removed, with lots of content I don't care about getting added - while price kept going up _and_ account sharing policies being put in that'd match my non-account sharing use case.

I'm still paying for Disney+ - though based on the Netflix experience I'm adding everything I'm interested in to my local library.

Amazon Prime got kicked out after they got too expensive - and even while I had prime I never actually used the video player as the UI is so horrible, but already back then pirated all the stuff I was paying for.

Almost 10 years ago - when I bought our current 50" TV - one reason was that large computer screens were unaffordable, bad to look at from angles, or both. I recently checked, and seems nowadays you'd be able to get decently large 4k-screens at similar cost than a TV. Just add a PC or whatever media players you want.

Pretty much all rumors at that time were very entertainingly wrong.

I think at the time that article got published we didn't even have the intel devboards distributed (that is a screen and macroboards, way before it starts looking like a phone). We did have some intel handsets from a 3rd party for meego work, but that was pretty much just proof of concept - nobody ever really bothered looking into trying to get the modem working, for example.

What became the N9 was all the time planned as an arm based device - exact name and specs changed a few times, but it still pretty much was developed as a maemo device, just using the meego name for branding, plus having some of the APIs (mainly, qt mobility and QML) compatible with what was scheduled to become meego. The QML stuff was a late addition there - originally it was supposed to launch with MTF, and the device was a wild mix of both when it launched, with QML having noticeable issues in many areas.

Development on what was supposed to be proper meego (the cooperation with intel) happened with only a very small team (which I was part of) at that time, and was starting to slowly ramp up - but massive developer effort from Nokia to actually make a "true" meego phone would've started somewhere mid-11.

Since roughly the first year of covid the supply generally has been quite bad. Yes, I can get _some_ xeon or epyc from HPE quickly, but if I care about specific specs it's also a several month long wait. For midsized servers (up to about 100 total threads) AMD still doesn't really have competition if you look at price, performance and power - I'm currently waiting for such a machine, the intel option would've been 30% more expensive at worse specs.

Not quite true - the intel projects were at a pretty early stage when Elop took over, and the whole Microsoft thing happened - and the projects got canned as part of the cleanup and moving to Windows for the phones.

The CPUs were indeed horrible, and would've caused a lot of pain if the projects had actually continued. (source: I was working on the software side for the early Nokia intel prototypes)

In the late 90s I switched from metager to google as it was just significantly better at locating what you was searching for. I'm now back with metager as it nowadays is significantly better at locating what I'm searching for.

Even worse - it's not uncommon to give the pasta a short rinse with cold water to make them "les sticky", and then complain the sauce isn't sticking.

Would be interesting to know which applications actually have problems with v6 - the example with directly using a v4 IP is more a user error, not an application issue.

I pretty much stopped submitting patches enabling v6 functionality to various projects back in 2005 as everything I cared about was working at that point. (Side note, I was just trying to search a few of those - but seems that period pretty much doesn't exist in search engine caches anymore. I knew the state of preserving internet history is bad, but I didn't expect it to be _that_ bad)

At least in Germany (possibly also other European countries) a design pattern only loading Facebook/Twitter/Youtube/... content with explicit user consent is nowadays pretty common.