Not really that surprising: all logic that used to be in the code is now in the model; the only code that is left is some glue to connect the outside world to the number crunching, just like Llama2 runs your LLMs with only 700 lines of C.
They're eating the code. They're eating the algorithms.
What works pretty well for me is the "i don't care about cookies" extension for firefox; my default privacy policy is to throw away cookies when the browser restarts, which I do a few times per day anway.
Th consent is about tracking and your data, not specifically cookies. If you accept them tracking and selling your data then deleting cookies only impacts one way that happens.
I disagree with this idea that businesses should have to keep their customers secret. If I go to Wal-Mart, then I should be free to tell my neighbors about what products were on sale and also how the produce was old / left to spoil. I’m not sure why that should be different for the store.
Do you think Walmart should be handing your credit card numbers out? Genetic profiles of you? Is there any limit or do you think if you walk into a space whoever owns that space can get and do whatever they want with any information you might happen to have on you?
> I disagree with this idea that businesses should have to keep their customers secret
They don’t. They just have to ask the person whose personal data it is if they can.
I don’t see how personal preference should control other people’s speech. When I put terrible Google reviews down for a shop… I’m sure they don’t want that said publicly either… but it’s not libel… what I’m saying is true. There isn’t generally value in concealing the truth.
Businesses =/= people and people are, or at least should be, entitled to more privacy. This reads like another variation of “you have nothing to fear if you have nothing to hide” but maybe I’m misunderstanding your point
That extension might allow tracking. From their Chrome add-on page:
When it's needed for the website to work properly, it will automatically accept the cookie policy for you (sometimes it will accept all and sometimes only necessary cookie categories, depending on what's easier to do).
Deleting cookies is insufficient because of browser fingerprinting, which you just consented to.
True, but considering that the extension was bought in 2022 by Avast, maybe it has its own tracking built in by now or will have something concerning done to it in the future. So even if the user does not care about cookies that much I would still recommend this new extension over "I don't care about cookies"
But this thread stars with someone saying they don’t care about cookies because they’ll delete them anyway. That’s different than saying they don’t care about their privacy, so it’s worth pointing out that accepting every cookie banner does have privacy implications beyond just having cookies placed.
I haven't watched it recently, but here are the main takeaways I remember:
Peltier coolers are neat because they're very small and quiet - as opposed to vapor compression systems solutions. However, they are an order of magnitude less energy efficient.
Also Peltier coolers still have to obey the laws of thermodynamics, which means that to cool one side of the mechanism, you must heat the other side. In order to do any substantial cooling, you need a way to dispose of that heat on the other side. This usually involves the use of radiators and fans, which negate much of the size and noise benefits.
As a result, Peltier coolers are pretty niché. Your use case would have to require only a little bit of cooling. You'd have to need a form factor that cannot accomidate a vapor cooling solution. And you'd have to be willing to make the system very energy inefficient.
AFAIK, no one has tried to build a Peltier cell paired with a heat pump. I am not an expert, but I would imagine that it's a path that could bring higher efficiencies. Thoughts?
Also not an expert, but I’m struggling to find a combination where one of those couldn’t be replaced with a passive thermoconductive element. It’s hard to beat the efficiency of “free”.
I think there are some applications though. I remember PWMing a peltier element to cool something to more or less exactly 35°C. I didn't need to be efficient cooling, it just needed to be reliable under space constraints.
I am no hardware guy and I remember there was a giant heatsink despite the constraints. It was some kind of photosensor + lamp if I remember correctly.
I think there was also some software logic to reduce water condensing at something too cool compared to the ambient temperature.
I know some people who are experimenting with using shorter certificates, i.e. shorter certificate chains, to reduce traffic. If you're a large enough site, then you can save a ton of traffic every day.
With half of the web using Let's Encrypt certificates, I think it's pretty safe to assume the intermediates are in most users' caches. If you get charged out the ass for network bandwidth (i.e. you use Amazon/GCP/Azure) then you may be able to get away with shortened chains as long as you use a common CA setup. It's a hell of a footgun and will be a massive pain to debug, but it's possible as a traffic shaving measure if you don't care about serving clients that have just installed a new copy of their OS.
There are other ways you can try to optimise the certificate chain, though. For instance, you can pick a CA that uses ECC rather than RSA to make use of the much shorter key sizes. Entrust has one, I believe. Even if the root CA has an RSA key, they may still have ECC intermediates you can use.
The issue with the lack of intermediates in the cert isn't browsers (they'll just deal with it). Sure, if they aren't already in the cache then there's a small hit first time. The problem is that if your SSL endpoint is accessed by any programming language (for example, you offer image URL to a B2B system to download so they can perform image resizing for you, or somesuch) then there's a chance the underlying platform doesn't automatically do AIA chasing. Python is one-such system I'm aware of, but there are others that will be forced to work around this for no net benefit.
That is a really good point. Googles certificate service can issue a certificate signed directly by Google, but not even Google themselves are using it. They use the one that's cross signed by GlobalSign (I think).
But yes, ensure that you're serving the entire chain, but keep the chain as short as possible.
This hasn’t been the case since TLS1.3 (over 5 years ago) which reduced it to 1-RTT - or 0-RTT when keys are known (cached or preshared). Same with QUIC.
Good to know, however "when the keys are know" refers to a second visit (or request) of the site right ? That isn’t helpful for the first data paquets - at least that what I understand from the site.
Without cached data from a previous visit, 1-RTT mode works even if you've never vistited the site before (https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/#1-rtt-mode). It can fall back to 2-RTT if something funky happens, but that shouldn't happen in most cases.
0-RTT works after the first handshake, but enabling it allows for some forms of replay attacks so that may not be something you want to use for anything hosting an API unless you've designed your API around it.
I have been developing Lua-heavy embedded products as a freelancer for about 20 years now, including VoIP devices, home automation controllers, industrial routers, digital video recorders, and more. These systems typically consist of a Linux kernel, some libc implementation, the lua interpreter and a few 3d party libs support libs to help building the app. The Lua apps ranges from 30k to 100k lines of code, depending on the application. Some of these devices can be considered 'small' in 2025 terms: 8MB of flash, 64MB of ram. Lua is doing great here.
All of these products are still alive today, actively supported and making my customers good money.
Some things come very natural to Lua: Lua <=> C interfacing is a breeze, and while some modern languages are still struggling to figure out how to do proper async, Lua has been able to do this for decades. The language itself is minimal and simple but surprisingly powerful - a few smart constructs like coroutines, closures and metatables allow for a lot of different paradigms.
For new projects at this scale, I would still choose Lua + C/C++ as my stack. Over the last few years I have been visiting other ecosystems to see what I'm missing out on (Elixir, Rust, Nim), and while I learned to love all of those, I found none of them as powerful, low-friction and flexible as Lua.
I am currently working on an embedded system with 264Kb of RAM and 4Mb of flash. Do you think Lua could be used in such limited settings? I am also considering the berry scripting language [0].
Assuming your flash allows XIP (execute in place) so all that memory is available for your lua interpreter data, you should at least be able to run some code, but don't expect to run any heavy full applications on that. I don't know Berry but it sounds like a better fit for the scale of your device.
But sure, why not give it a try: Lua is usually easy to port to whatever platform, so just spin it up and see how it works for you!
I haven't worked on a system that limited (not even OpenWRT routers) since a dev board in college.
The experience I had there might be your best bet for something productive. That board came with a 'limited C-like compiler' (took a mostly complete subset of C syntax and transcribed it to ASM).
You'll probably be doing a lot of things like executing in place from ROM, and strictly managing stack and scratch pad use.
The 64MB of RAM and 8MB (I assume that's 64Mbit) of ROM allow for highly liberating things like compressed executable code copied to faster RAM, modify in place code, and enough spare RAM otherwise to use scripting languages and large buffers for work as desired.
It's more than generous. You can run it with much less resource utilisation than this. It only needs a few tens of kilobytes of flash (and you can cut it right back if you drop bits you don't need in the library code). 32 KiB is in the ballpark of what you need. As for RAM, the amount you need depends upon what your application requires, but it can be as little as 4-8 KiB, with needs growing as you add more library code and application logic and data.
If you compare this with what MicroPython uses, its requirements are well over an order of magnitude larger.
This article is partly wrong, and partly nonsense. Apples and oranges. But still:
> Work with only 3 files [...] Boot in under 5 seconds [...] Use commands without spaces [...] Run CPU opcodes natively [...] Be real
I have a little PCB here on my desk that runs linux with 2 files: vmlinux and busybox. It boots in about two seconds and yes, it runs CPU opcodes natively.
I'm not sure how being able to use commands without spaces or running in real mode is considered better or worse than the alternatives.
On the other hand, when Linux was new (I switched to Linux in early 1992), you could install it all on a floppy and boot in a few seconds. Not much difference really. Just way more flexible with a Linux floppy than a DOS one.. I kept a Linux floppy around for doing various stuff with problematic PCs.
It's way more important (or was, at the time) that MS-DOS could run on 8088/8086 and '286, unlike regular Linux.
Not sure what you mean by practically usable Linux kernel. It was perfectly possible to use the < 1.0 kernels on a floppy, with enough tools to do useful work.
I'm afraid it would: in 2002 I was involved with the development of a very early wifi AP implementation at Freehosting; this was running uclinux on an ARM7 with a pretty bare kernel and the whole OS fitting in under a megabyte. Booting was already pretty much instantaneous then.
But this is an artifact of a distant past, a small glimpse of the Geocities era. We would write whatever was interested to us enjoying the whole process. Look at the Lisp "article":
just a few notes with the conclusion "Well, that's enough LISPing for now. I may add more to this page if I actually ever learn anything else about LISP."
For me this submission isn't so much about the content, rather about how different the world was back then.
Well, the whole point is that it isn't a [censored] snake on a [censored] plane, and I think the title is already a pretty clear allusion to SoaP as it is.
They're eating the code. They're eating the algorithms.