finaard

Maybe to get an impression that they'd be performing like them - but not actually performing.

It helps me being lazy because I have a rough expectation of what the outcome should be - and I can directly spot any corner cases or other issues the AI proposed solution has, and can either prompt it to fix that, or (more often) fix those parts myself.

The bottom 20% may not have enough skill to spot that, and they'll produce superficially working code that'll then break in interesting ways. If you're in an organization that tolerates copy and pasting from stack overflow that might be good enough - otherwise the result is not only useless, but as it provides the illusion of providing complete solution you're also closing the path of training junior developers.

Pretty much all AI attributed firings were doing just that: Get rid of the juniors. That'll catch up with us in a decade or so. I shouldn't complain, though - that's probably a nice earning boost just before retirement for me.

If you're using kitty and have terminal related problems the easiest solution usually is just not using kitty.

> If I had to choose a language that is furthest from Perl, it might be Lisp.

The two languages I enjoy the most are Perl and Lisp - and the majority of my non-work related coding is split between those two.

Today is probably a good day to make Jell-O without alcohol, for the kids, though I might have some explaining to do.

Some years ago they asked me to have Jell-O, and - thinking of Lehrer - I replied that it's adult only, as you make it with alcohol. Much to my surprise that explanation stuck - and they never had Jell-O so far.

A transplant always is a life altering change. You'll be on immunosuppressants for the rest of your life which has a massive impact on your quality of life - and that's _if_ you get a transplant before you die.

I have no idea how I'd react in that situation - but I can understand people who'd rather not. Especially considering that you might not want to take one of the few organs from a person who might be willing to fully commit to that.

This is GPT hooked up to a simple turtle graphics implementation so it can try (and often fail) to draw requested shapes in an Emacs buffer.

Uses gptel, so also works with a number of locally hosted LLMs, as long as they have tool support.

Code is here: https://github.com/aard-fi/buffer-turtle

N9 was very close to launch when Elop came, so that went ahead, but the rest of the development got cancelled immediately to focus on Windows phone: N9 would've otherwise been the first in a series of devices to slowly take over from Symbian.

Until Elop canceled everything Symbian was still selling - declining sales, but still millions of units. So while the situation was bad slowly phasing out Symbian for taking all the money you could make with that, while hoping N9 software stack sticks sounded like a more sensible approach than "cancel everything, go for Windows". Elop did respond to criticism from Developers (including a mail I've sent him with colleagues), but had made up his mind.

This blog post is a byproduct of that discussion, and was referenced by Felipe in internal mailing lists back then:

https://felipec.wordpress.com/2011/02/22/meego-scales-becaus...

I have no idea how successfull it'd have been in the end - the UI was great, parts of the softwarestack were problematic (though we've been doing quite well with parts of that at Jolla later on). The planned hardware for the future models was less than ideal, though.

I didn't write scalable, I wrote sustainable. By that I mean that the longer term impact on society will be negative, compared to options they've been replacing.

One writeup about some of the airbnb issues is here: https://www.theinvisibletourist.com/why-you-shouldnt-use-air...

Any of the other gig economy setups have comparable issues. For food delivery it is now more expensive, with worse conditions for the drivers. Here in Finland unfortunately they deregulated the taxi market as response to uber (instead of just doing the senible thing of just banning it) - as a result taxi market is a mess now, and I've avoided taking a taxi or comparable services for years now. I'd rather walk.

> As always, their policies failed to account for context.

So seems that's not a first for her - and that kind of experience is expected by any gig economy scam once they managed to reach a decent market share. So why is she still using it?

From the very beginning I've refused to use that kind of gig economy services as their business model just isn't sustainable in the long term without making things worse for us - but thanks to idiots like her I nowadays have to deal with that nonsense in some cases (like food delivery) as people just jumping at "cheap now" without giving it any critical thought managed to kill of the sustainable alternatives.

It's quite nice to see how technology has developed since then. A few years ago I wrote a wrapper around the openttd server to allow easier hosting (as well as putting it in a chroot) - now with docker/podman/... something like this is way more accessible. I've just created a mirror of the old repository on github, in case anybody is interested in that for historical reasons: https://github.com/bwachter/ttd_addons

https://github.com/bwachter/ttd_addons/blob/master/ttdconsol... is another example of progress - if I remember correctly at the time I did this inotify was in development outside the kernel tree. Nowadays solving this would be trivial with inotify on Linux - and other UNIX variants also mostly gained some form of file monitoring API.

I was thinking child friendly, so using NFC tags isn't such a bad idea - plus I have a few hundred spare ones in nice plastic casings. I'd also just store IDs on them, and either have the media files preloaded (as seems to be the case here), or have it download it from my media server on first use.

Other thing I want (which they don't do) is the ability of resuming playback at the same position, even when putting it into a different player - that's one reason I still have some audio cassettes for the kids. No other medium I'm aware of does that kind of easy state saving. My idea there is to have the tags locked in the player in a way that gives me enough time to write the position if the user tries to remove it.

You can, by using the libhybris hardware abstraction layer I've mentioned. It is relatively simple, though still requires understanding of how low level stuff works. The main problems there are graphics and modem, both of which typically are not open drivers - and with that you then pull in half of your typical android system into your regular linux distribution just to get the hardware working.

If you don't care about the modem and graphics acceleration (or, in same cases, graphics output at all) you should be able to get it booting with the available kernel relatively easily.

Camera also tends to be not tends to be not that much of an issue - typically there's enough in the available kernel that you can get a gstreamer pipeline running, and then just have to figure out how to make it not look completely shit.

And after all that you still end up having a device with the baseband sitting on your SoC.

The problem is the hardware, not the software. Also, what you want as a paranoid person is your baseband not part of the SoC running your computer - this project hear does that, Jolla and others are using standard Android SoCs.

Jolla added libhybris to make it easy to use Android hardware adaptations - which at that time was needed to get a phone out (ste, which the first Jolla phone was supposed to be based on, decided to get out of the phone chip business during the prototyping phase, and that was the last vendor offering proper Linux drivers). I never was much of a fan of that as you just pull in way too much uncontrollable crap - unfortunately it works good enough that a lot of other projects then also jumped on that, instead of reviving a focus of doing proper Linux drivers (something I was worried might happen when the libhybris development started).

This is pretty interesting to me for two reasons.

First, I just came back from Germany where I've seen that thing in a shop. Didn't have much time to investigate due to the kids, but guessed that it's just NFC chips with data on the headphores.

Second, I've been thinking about building a simple MP3-player for my kids for quite a while now, and (minus the obfuscation there) that's not far from what I've been thinking about doing.

I used a Blade 2000 as my main machine until the early 2010s. Doing UNIX work on Windows back then with cygwin was way more painful than it is nowadays, and the hardware was a lot nicer than x86 desktops (and workstations offering things like ECC would've seen you in the same price range anyway).

Back then with just dual cores running heavily loaded VMs always was annoying, and slowed your main system down noticeably - so I preferred not doing that on my x86 box. My Sun on the other hand had three SunPCI cards I used for Windows development and testing - which had pretty decent performance, still allowed me to have the disk images on my UNIX filesystem, but didn't ruin my native performance.

We're a tiny company doing ops as services for large corporations - with one customer now coming close to a decade. That solves the retaining problem as we have limited exposure to all that big corporation nonsense, and have the option for individuals to go on a vacation in other projects without losing their knowledge in the organisation.

The CPU would've been good enough for a lot of things (especially the later revisions) - but it has a lot of other flaws.

A big annoyance is the screwed in acrylic sheet on the bottom - it looks cool, but it makes access very annoying. For something designed to be tinkered with I'd have wanted some quick access solution.

Next is lack of internal USB ports - there are just enough for the peripherals. Now there's enough space in there to add an external USB hub, but it'd have been way nicer to have an additional USB hub on the board, and a bunch of ports you can plug stuff in.

The CPU cards all have a different set of outputs supported - which is annoying, but I was expecting that based on other experience with projects trying to do that kind of modular system. Reality ends up having incompatible interfaces on your SoCs, and then you and up having to do the best with what you got handed.

RAM is also a bit of an issue, but for the use case tolerable (at least for the later modules).

My biggest issue (and main reason I'm rarely using it) is the keyboard, though - I was hoping for a good keyboard after all their talk about mechanical, but it's by far the worst keyboard I've seen in a notebook over the last decade.

The correct one is the one that doesn't get you yelled at and possibly banned by the rest of the channel.

Most of my money comes from companies unable to handle even simple setups - and having trouble to find the right people, so I somewhat agree too. But it's mainly an education problem - it's pretty much impossible to find good people with that skillset, but it is possible to find people straight out of University willing to learn.

Thing is, by the time the cloud native stuff makes sense most companies are at a scale where it'd be cheaper to just hire a good devops team, and start building your own cloud infra on own hardware.

> and Finally...... AMD.

I don't think AMD would get enough out of that to make it worth for them. And that's before you take into account that a condition of that merger would be spinning off the x86 CPU business to a separate entity to avoid a monopoly there.

The big loss maker here is the fab business - and AMD realized a long time ago they're better off without their own fab (and got heavily criticized back then) - so why would consider investing a shitload of money for a bit of IP just for having to deal with spinning of fab business yet again?

> Could be something relatively simple such as "testing passed, so lets mark the file with a version number and release it".

I'd argue you shouldn't even do that. When I've been building CI systems pushing stuff to the customer in the past we've always been automatically versioning everything, and the version that's in the artifact you've found to be good is just the one you're going to be releasing.

[flagged]

Long time ago I was working for a web hoster, and had to help customers operating web shops to pass audits required for credit card processing.

Doing so regularly involved allowing additonal ciphers for SSL we deemed insecure, and undoing other configurations for hardening the system. Arguing about it is pointless - either you make your system more insecure, or you don't pass the audit. Typically we ended up configuring it in a way that we can easily toggle those two states, and reverted it back to a secure configuration once the customer got their certificate, and flipped it back to insecure when it was time to reapply for the certification.

I just remove cookie popups with ublock origin. Nobody annoyed me enough yet to see if they're compliant afterwards - pretty much all pages work properly after that, and they'd need to handle that case as selecting the refusal button.

A while ago I hooked up the ambient light sensor of android devices as morse input for Emacs: https://www.youtube.com/watch?v=IBrvhiiZyf8

With the Centro it was pretty amazing when they dropped a maps application later on - as it didn't have GPS. In built up areas they managed pretty impressive accuracy just by cell tower triangulation.

I still miss the calendar and contact apps from the Palm. I stuck with Palm up until the Centro - and haven't found contact/calendar apps I'm as happy with as the Palm versions yet. They're either missing some simple basic features, or the UI is needlessly complicated.

I still have a section on my homepage about how to create and flash custom ROMs for the Palm Vx - and somewhat surprisingly, I still now and then get emails from people asking for help with that.

I was living through that era with a zoo of Unix variants to build for (including, but not limited to, AIX, HP-UX, Solaris, IRIS, Tru64 and various Linux flavours) - and I always was excited about stuff that did just have hand rolled Makefiles, as that was something that was way easier to fix as the average software using autotools.