AI often produces nonsense that a human wouldn't. If a project was written using AI the chances that it is a useless mess are significantly higher than if it was written by a human.
Folding bikes are the answer there IMO. You can just bring it into the office. You can get pretty good electric ones too now (probably a requirement for SF).
I can already bring my regular bike in the office. The problem is when you're meeting with friends, going to a restaurant, well anything that's not commuting to work...
It's one of those just-so stories that sounds like a nice neat explanation. You can't put the complex reality into a neat single sentence so nonsense like this is always going to win.
I don't think the vibecoding jab is warranted, but I agree this is a pretty terrible UI for electronic circuits. Schematic capture exists for a reason! It's not even difficult for beginners to understand if you have a decent UX (which for some reason seems to elude 90% of PCB software).
google is giant and chaotic, and chrome likely is spagetti code mess. Its hard to tell if their approach is reasonable and fully implemented without digging deep.
I work on such project, where we use simplified C++, and it works fine, no memory corruptions in my experience.
> Also, Ubuntu using a non-GPL licensed userland means they can pull all kinds of tricks to allow more TiVoization in the Linux ecosystem.
Can we stop this conspiracy nonsense? They have explicitly stated that licensing was not a motivation, and even if you think they're lying it wouldn't make any sense anyway! No Tivoization is foiled by Coreutils being GPL. That's ridiculous for so many reasons, not least you can just use the BSD versions, as Apple does (and they still release the source code!).
Because GPL doesn't play well with static linking, the new favourite of programming languages rediscovering the pre-1990's ways of most operating systems linkers (aka binders).
The license has been decided way before my time. I am 0 interest in starting a license debate (I care if the license is DFSG - Debian Free Software Guidelines) and spend time on it. I would rather use my limited time to make rust/coreutils ready for production.
From what I understood, they don't "believe" in GPL and don't like the idea of "having to keep it open". They believe in Developer Freedom(TM), not User Freedom(TM), so they don't care whether their code is closed by others or not.
To summarize #834: We don't like GPL. We'll do MIT, thanks.
If they can earn my trust, why not? I'm not a pointlessly stubborn person. I have changed my views in the past, and can certainly change in the future. This my view resulting from my experiences, and jury is still out from my perspective. If you want to trust Canonical and Co., you can. Don't let me stop you.
> They have explicitly stated that licensing was not a motivation, and even if you think they're lying it wouldn't make any sense anyway!
Who prevents forking Ubuntu and taking that extra mile, esp. now we have a company which wants to enable exactly that lockdown?
> No Tivoization is foiled by Coreutils being GPL.
Belts have holes. They can be used to hold or to choke. Adding more holes to a belt allows more different uses.
> That's ridiculous for so many reasons,
Can you give me more reasons to believe me that I'm a tinfoil wearing crazy weirdo?
> not least you can just use the BSD versions, as Apple does (and they still release the source code!).
Same Apple removing any GPLv3 (and possibly GPLv2) tool from their roster in every iteration from their OS. Same Apple which provides no way to verify that what's published is what's running on their hardware. Same Apple which provides SIP to seal their system partitions which can't be modified without breaking tons of guarantees and seals. Same Apple which controls from their processor to software, without any gaps.
Having the source have no meaning there. You can't use that source. You can't modify the machine you use, you can't install any other OS or just test something.
If the Linux driver is GPL and he made the new driver using AI to essentially copy it then claim that the result wasn't covered by the GPL... It's an area not settled by law yet.
Still not as bad as the guy who paid for a commercial license for some Linux driver, fed it into Claude to get it to update it to the latest Linux, and then released it as GPL! That's definitely not a grey area.
It's clickbait. The "driver" is actually a rather comprehensive kernel patch that modifies existing GPLv2 kernel code, so by its very nature it is at least GPLv2 (original parts may be dual licensed by the vendor if they want to, but they can't not make it GPLv2).
What this person paid $40,000 for is access to development kits for certain hardware, which with chip vendors like that usually also comes with support. The vendor cannot prevent you from exercising your GPLv2 rights after they hand you the code.
In fact, if you manufacture and distribute a device that uses these kernel patches it becomes your obligation to enable your customers to exercise their GPLv2 rights. Chip manufacturers know this and (if they are somewhat reputable) usually license their code appropriately.
At least there's a good reason there - they're easier to clean. That's not much of a concern with microwave controls.
But I disagree with the idea that we don't need precise times on a microwave. The article / book disagrees with that, and the think I most regularly microwave (milk for my kids) needs 1 minute 50 seconds. 2 minutes and they'll reliably complain it's too hot.
The real problem with microwave UX is that the interfaces are often simply bad. People think the power/time dial interface is good but that's because it's difficult to mess it up (though they usually manage anyway by having them go up to 30 minutes or whatever).
It's really easy to mess up a button interface but you can also do it well. My microwave is close to doing it really well. You press a high/med/low button, then 1s/10s/1m/10m buttons to the desired time, then start. The only things they got wrong are that it requires pressing the power when 99% of the time you want high, and you could probably get a more useful distribution of time increments (I'm literally never going to use the 10m button).
But apart from that it's nicer than dials, which are often very cheap and imprecise.
I've never had an issue cleaning the dials. They're smooth hard plastic, and they don't get particularly dirty.
>though they usually manage [to mess up the interface] anyway by having them go up to 30 minutes or whatever
What's the issue? I've microwaved that long before.
>My microwave is close to doing it really well. You press a high/med/low button, then 1s/10s/1m/10m buttons to the desired time, then start.
We're very different people! That UX sounds dreadful to me, one of the worst I've heard (and unfortunately encountered).
Enter time on the keypad, optionally press Power and enter that, press Start. Also needs a Plus 30s button. This is the one and only correct way to implement a push button microwave. ;)
I count five presses instead of 3 to get 90 seconds, including one way that's just pressing the same button 3 times (+30s).
>needs 1 minute 50 seconds. 2 minutes and they'll reliably complain it's too hot.
Seven presses?
The dial microwave I use can distinguish between those two. It helps that the shorter times are given more room, so you can adjust them more precisely. 1:50 vs 2:00 will make a difference in my experience, but 7:50 vs 8:00 generally won't.
You could have a hybrid approach of course, but then I suspect the engineering tendency would be to "lock in" the time after starting the oven, so it can't "accidentally" be changed.
Looking for a photo of my microwave dial, I came across this surprisingly relevant post:
> What's the issue? I've microwaved that long before.
Really? What for? Anyway the vast majority of microwaving is going to be in the 1-5 minute range. By making the dial linear and giving it a huge range up to 30 minutes, you end up making e.g. 30 seconds and 1 minute impossibly close.
The commercial microwave oven someone else linked had a solution - make it logarithmic.
> Seven presses?
Eight actually, but it really is quicker and easier than doing the same with a dial though. I agree it could be optimised though. It shouldn't be necessary to select the power and a 30s button would be good (down to 5 presses).
The vast majority of microwaving is in the 1 to 5 minute range only for those who use a microwave oven only for reheating.
For cooking, times from 10 to 15 minutes are more frequent, though things like potatoes or sweet potatoes need only 7 to 8 minutes. Only a few delicate vegetables or fruits may be cooked in the 1 to 5 minute range, e.g. onion, garlic, leek, parsley and dill, etc. Meat needs to be cooked at low power, which in turn requires long times, typically over 20 minutes. There is also a very small number of vegetables that need cooking times over 15 minutes, e.g. the common beans, for which even times of 30 minutes may be needed.
That said, all the microwave ovens that I have used (in Europe) had rotary knobs with variable resolution, fine for short times and coarse for long times.
For many years, I have also belonged to "most people" and I was cooking in one of the weekend days by traditional means, which required many hours, then in the rest of the week days I was reheating the food in a microwave oven.
Only a few years ago I began to experiment with cooking raw ingredients in the microwave oven. After discovering how much this simplifies cooking I regretted very much that I had not tried to do that earlier.
Because cooking at microwaves is much faster, nowadays I cook most food immediately before eating it.
I have used only microwave ovens with rotary knobs.
They had a finer resolution of 10 seconds for short times, then the resolution was progressively coarser for longer times, e.g. of 30 seconds for times over 10 minutes.
This is perfectly adequate for finding optimum times, and I cook in a microwave oven all the food that I am eating, from raw ingredients.
This is cool. I bought an Inkplate for this and got as far as writing a custom image format suitable for e-ink sort of things (4-bit RLE; trivial to decode, but good compression for diagram/text type images).
Where I got stuck is calendars... Unfortunately Google Calendar doesn't seem to provide a nice API where you can just say "give me the events for these days", instead you can only download all of your events in iCal format. It's then extremely non-trivial to convert that information into "what is happening today".
There are several ways to get all events for the day! The easiest one in my experience has been to write a simple Apps Script project and expose that as a published Web App[1]. That moves all of the oAuth logic and Calendar API plumbing to Google's server-side code, and gives you a simple long URL that contains exactly what data you want.
Something like:
```
function doGet(req) {
let start = new Date();
start.setHours(12,0,0,0);
let end = new Date(start);
end.setDate(end.getDate() + 3);
let events = CalendarApp.getEvents(start, end);
return ContentService.createTextOutput(events.map(x => x.getTitle()));
reply