My first year Chemistry dissertation was about this. Of all the useful things you can do with hydrocarbons burning them is the most wasteful.
FLOSS virtualization hacker, occasional brewer
My first year Chemistry dissertation was about this. Of all the useful things you can do with hydrocarbons burning them is the most wasteful.


On the other hand it’s legitimately one of the wonders of the digital world. A communally edited source of knowledge free for all to access. While it’s good to scrutinise foundations and how they are run I’ve not seen anyone propose a better solution so far. The data is freely licensed so forking is possible but it’s not really the technical details that make Wikipedia the resource it is today.


If you can get your reproducer in a one liner, e.g:
cd builds/bisect && make clean && make -j(nproc) && make run-failing-test
then it’s super easy to pass that to /bin/sh -c “…as above…” to feed to the git bisect command
What do you need/use that you find in modern editors that you can’t get in something like Emacs? While there are AI integrations for Emacs they are all optional.


Mine are all GPLv3 or forks of other repos and they are listed. I’m sanguine because the license allows for study and if it’s good enough for humans I don’t see why it’s not for clankers.
I’ve long been off the critical path because as a tech lead I have a lot more random stuff (and meetings) to deal with. I’ve been able to vibe code some non-production stuff like scripts to unify feature lists across JIRA, specs and the upstream docs which has helped free up time to hand craft more code on production.
I don’t care too much about the quality or maintainability of those scripts as long as they make my life a bit easier. I do care about the maintainability of the production code base.


The last big update to my git workflow was when I discovered --update-refs as it makes maintaining a stack of feature branches much easier. So far I really only have one “main” dev branch and then peel off the sub-branches at they need merging upstream.
However I shall have to investigate how the history commands are exposed in magit. I can see it being useful if you have long held branches that take a while to upstream but are useful to have in your trees.


In QEMU all of our CI environments are replicable locally as docker/podman images. However usually flaky CI is due to races exposed on overloaded runners so I often also run make -j(nproc) at the same time to simulate that. A retry script is also useful to get an idea of how stable a test is. Having sanitizer builds can also help.


I thought Episode IV was in the initial crawl text.
ETA I’ve just checked and apparently it was added in the special editions, the original 1977 crawl just started with the story.
It’s 3.
Perfect framing is often a giveaway. Most people’s phone footage wobbles and moves around. Background object permanence is another thing to look out for
The Corridor Crew have done a couple of videos where they explain a lot of the things to look for and the reason AI finds it hard. Some examples:
Is this a sign of Lemmy’s popularity that we are now getting thirst spam?


Because running servers costs money. The project I work on gets donations towards it’s CI costs and it’s not insignificant.


I personally have email integrated into my editor (mu4e) so I can apply patches and search code directly from the email thread. It handles threads and searching really well.


Your making a big assumption extrapolating from one particular study involving Java code and a static analyser.


How is that patch sloppy?
I feel the term slop is being overused to cover anything an LLM has touched. If I ask an agent to re-read a mail thread for me and apply the changes to my tree to review is that slop? Would you feel better about it if I copy and paste from email to code in my editor?
I’ve just been doing a bunch of bug triage which was mostly driven by the agent although I checked the issues where it had commented. Was that slop? Ironically a lot of the issues where AI generated although for the most part more complete than a lot of the purely human submissions we get. Are those bug reports slop? What about the poorly drafted human ones?


That’s not kernel policy but LF guidance. From the kernel’s point of view patches still have a high bar to pass to get merged and I don’t think we have enough data yet to see if LLM based submissions to the kernel have a higher or lower error rate than humans.
I certainly feel the uptick in LLM reports though - one of the projects I’m working on is seeing a deluge of them at the moment.


I’ve vibed a bunch of apps and scripts and it’s great for that project you never found time for. Importantly they where all local and ultimately throw away things.
The idea of relying on vibes for production seems insane to me. The most important thing about software engineers is not how fast they can type.
At 43 that’s probably a little earlier than the OP expected and if their daughter wasn’t planning on starting that early it’s going to affect school and job prospects.
That’s not too say it can’t work. One of my in-laws had their first at 18 and now as their last leaves for uni they are still fit and young enough to enjoy the empty nest experience.
Plastics, waxes, solvents, synthetic fibres and even pharmaceuticals. There are second order products from cracking like hydrogen which are important for things like fertilizer but that is rather carbon intensive.
You can use organic oils for some of these. However organic oils are more complex so need to be broken down into simpler building blocks which all takes energy and processing. Of course you also need to grow oil bearing plants which also tend to require a lot of fertilizer.