adql

Futile wish. Even if you controlled the modem entirely the "other side" can do whatever they want with your packets.

If you have small pre-defined sets of events in data structures that compress well. That is not the case for any real system.

> And so of course if you have to optimise things, you would need to drop some information you pass to the events, but you would need to do the same for metrics (reduce the number of metrics emitted, reduce the prometheus labels,...).

Those are entirely different orders of magnitude both when it comes to size and how much usefulness you lose. In modern storage backends like Victoriametrics a counter gonna cost you around byte per metric per probe. And as you emit them periodically, that is essentially independent of incoming traffic

Capturing the requests into event/trace/whatever other name they gave to logs this month is many times that and is multiplied by traffic.

>It's funny you can easily spend 10-15 USD more and get a product that will last you 5 more years

....or not and it will fall apart just as quick if not quicker.

I wish if it was just "pay us extra and it will last longer"

Soo much that. I just want stuff that doesn't fall apart. I don't care much for fashion, I just don't want to buy pants every 2 years

Every single shirt I ever bought lives at the very least as shop rag; but it's kinda hard to upcycle pants material

Having house be store of value/investment rather than commodity is a big part, it's not just "getting permission is hard", because as long as it is a an investment, everyone that has housing will do everything in their power to keep the status quo, including pushing the lawmakers to make it hard to do anything that would lower housing value.

Better that than sexual repression leading to more rapes like in the more "puritan" countries...

Dunno, is US government funding production and shipment of it like they did for drugs ?

If they are not I wager chances are higher

...why ? it seems to be mostly about making sure content itself is, well, not illegal, not deanonymizing users

I hesitate to call "the shit that keeps stuff older than a year working on that kernel" a tech debt. It's necessity in any general use OS.

The stuff that can be changed without breaking compatibility is, well, it was the developer's best idea at the time and some of them turned out to be good, some turned out to be bad.

Going "but on paper that idea would be better, let's make OS around it" rarely ends up being plain better. It's not one dimensional.

For example if your CPU scheduler makes all jobs run faster (less cache thrashing while keeping CPUs busy etc.) but is unfair, that might be great for people running batch jobs, but shit for desktop users.

Scheduler wasting cycles but making sure interactive tasks get the right level of priority might be improvement for desktop users but not for server use etc.

Or you figure out that the reason something was "unnecessarily complex", was actual necessary complexity that wasn't obvious at first.

Also Linux isn't exactly stranger to taking the whole bunch of code and replacing it with something better, I think we're at 3th firewall stack now (ipchains -> iptables -> nftables)

> I don't want to say Linux is free, in practice it's not, those who are running the big powerful machines are using RHEL and paying hefty licenses.

Google/Amazon/MS isn't paying RHEL licenses.

Reason for using RHEL is basically "we don't want to hire experts", which makes a lot of sense in small/midsized company but in big one it's probably mostly the ability to blame someone else if something is fucked up, and the fact some of the software basically says "run it on this distro or it is unsupported".

Lawyers get paid to bend the law in your favour. There is nothing moral about it.

Can we stop treating corporations as people?

But you're losing investors money not your own

Utopia like that requires people in power to work toward it, not their own bank account state.

No tech is going to change that.

Other way to do bitbanging without being (as much) dependant on task timing is using DMA engine to just dump the state of pins and parse it after. Same thing with outputting when you need precise timings, no need to burn a core to bitbang if DMA engine is featureful enough.

No it does not. If people took so much care about writing technically correct things (instead of random observation with no substance) as they did whining about irrelevant details the snark wouldn't be needed in the first place

And g-code is still in use till this day

I don't think one of biggest tech giants in control of the "best" AI company out there is beneficial to customers...

> I gotta say I don't deeply understand ActivityPub, but one of the first things I thought when trying to grok it was "how does this improve on RSS?". Like another commenter here I think a big part of it is that it's JSON and not XML, but I think another thing people would say is that you aren't storing things locally, that is you don't have an application pulling things onto your local machine (phone, laptop, whatever).

Both of those honestly sound like a disadvantage. Like yeah , plenty to hate about XML but at least it has defined schema language, and I want to have an application and not be dependent on some shitty website to act as aggregator for me.

All of the "features" ActivityPub has could be pretty easily just added to RSS too

> How do smart watches (like the Garmins with 1-week batteries) do it?

https://sharpdevices.com/memory-lcd/

And biggest one is cloud.

We went from sending our code to run at mainframe owned by big corporation and leased monthy for a price to sending our code to big corporation to run at not-mainframe for a monthly price

I'd love big reflective/tranflective display but I'd imagine because of rarity the prices would also be pretty high

The time period is asinine; 20 years is forever in most industries

even just x10 cheaper would put it at double the price of LCD and that already has uses

Yeah I'd love to have big display/dashboard on a wall that isn't acting as extra light in the room but not at those prices.

Transflective LCD is other option bit also pretty hard/expensive to get a big screen...

That's a very good change. You should never have a reason to vomit your app's deps into system, far too easy to cause problems on upgrade

Those are upstream Debian changes. Well, not setting Wayland default or QAing it for rpi but still, most it's a Debian's team job

> I believe one of the biggest reasons is that because the boot process is very different from the way debian does things, it ends up needing significant changes from the starting tasks to do things. Along with that I think the original 32bit RPIs didn't support some version of the compiled binaries in the debian arm repos which meant that they weren't necessarily compatible.

No longer correct. Debian on new rPi "just installs" and boots. I think that also worked fine on rPi3

https://wiki.debian.org/RaspberryPi

The problem is that many things have not been upstreamed into kernel so some stuff doesn't work or work badly. Like trying to get video just made the video device return random block of memory instead of an image last time I tried

> These days on the 64bit version, I'm not sure why it needs that much either. I'd think that having a few new task-* metapackages that setup the boot and raspberry pi specific boot management stuff should be doable and then they could use the main debian packages I would think. There's probably something that's not obvious that makes things just incompatible enough that it isn't simpler to manage that way.

I'd imagine the answer is "iteration time". Far quicker to apply a patch fixing some rPi-specific issue if you have your own repo with everything.

Pushing it to upstream of Debian might take few days and might come back with "well that code isn't great, fix it".

Even more if Debian maintainer says to take it up with original project, which is the right way to do it, just slower one.

> And How do you say the opposite of sugar syntax in English?

Syntax spice ? It burns when you eat/read and it burns when you write/poo

> Because my lovely rustlang has a lot of sigil chars as old Perl, it makes me sad.

I unironically prefer Perl mess, at least you don't have macros and annotations generating who-knows-what at random parts of code.

I mean, not that you couldn't in Perl, there is plenty of horrid things you can do using some more obscure Perl's features (my favourite so far was modifying other package's package-scoped variables), but most code in Perl doesn't.