The threat model is the one where software authors are compromised, but would like to pwn you discreetly.
If the software is distributed through your distro's package manager, there's a good chance links to source code are pinned by hash, changes to package build scripts have to pass some review, and each change leaves a paper trail in distro's repos, mailing lists.
If it's just some script passed over https, some guy with enough access rights could replace it for 1h or a day on a weekend, own a few people, and leave no way to prove it happened. Even if a owned user investigates this, they'll have no way of proving that this https server was giving out a malware last Saturday.
The problem with this approach is the everyone does build their own implementation of these ideas and those then don't compose. I've seen C codebases that had to deal with over a dozen (incompatible) string abstractions, for example, because the core language doesn't give you a usable one and every library that wants one implements a subset of the features than a generic one would provide. I've also seen C codebases with multiple incompatible hash tables, where switching a piece of code between them was a major refactoring effort because there was no common interface and their semantics were subtly different.
but as long as you work with a couple of linters, it's very fast to develop with and you can be reasonably confident in your code.
I disagree on this if you use any of the concurrency features. Go makes data races UB (and will break memory safety on some of them) but provides nothing in the type system to determine whether you've aliased something that you've captured in a goroutines or sent over a channel. There are some linters that catch the obvious bugs, but the fact that objects in Go can be arranged in any arbitrary object graph means that you can't (in the 'not computable' sense) solve this in the general case with static analysis.
But Go as a mostly single-threaded thing, maybe with the occasional goroutine for some background processing in the limited situations where you can reason about ownership of everything the goroutine captures? It's fine. Much simpler than Python, runs faster, trivial to distribute.
Depends on which people. Developers offering curl | sh is low standards and sloppy work. A user running that when the alternative is packaging the software yourself, is understandable.
The main problem of curl | sh is not security, it's that it makes your workstation more of a snowflake server. Those scripts are usually not written with robustness in mind, the degree to which they respect conventions of Linux distros on how to install stuff varies. Is there an uninstaller? Will it work after a dist upgrade? Does it touch things other components depend on? Will it break something today or a month from now?
Enough curl | sh invocations and your machine needs a "Linux reinstall" because too many devs have put too many undocumented artifacts on your system with their unwashed hands. We're not on windows.
An alternative does exist: package your software, do your job instead of making your user's pay for it. Take that switch-case statement in install.sh that checks for user's distro, and write packages for the three distros yous support there. In the age of LLMs, it costs nothing, packaging is specifically that repetitive routine kind of work with no need to do "system design" that LLMs are really good at.
Working, but also being anxious about my career. I won't be too specific as to not sour the mood too much, but the recent developments have me uneasy about the LLMs and our industry as a whole. I'm not necessarily worried I'm gonna be replaced on a technical merit, but on an economical one. More and more companies are drinking the Kool-Aid and it feels like just a matter of time until mine does too and starts buying into the alleged "cost savings" and optimizations. This is a problem because I don't have a degree and my health issues would make it difficult (if not impossible) to perform many other jobs.
In short, I'm going to try and think about possible options if working in tech ends up not being feasible, happy to read any recommendations you might have!
Other than that, I started reading a friend's blog post on adders (ripple carry, carry skip, etc.), and since I lack formal education in that regard, I'm taking my sweet time digesting and understanding it. Started a side project to aid me in that, namely a visualizer where you can put a bunch of different logic gates, connect them with wires and go through the process step by step to better understand it. Sebastian Lague's video is a big inspiration, but I'm not aiming for something as general purpose as that -- I want this toy to satisfy mostly my needs and potentially be helpful to others.
It's a multiply-interesting confluence of tech, IMHO.
It is a new effort at a swiping keyboard, since Microsoft owns the best and killed it
It used a local LLM but it's privacy-first, offline -- the opposite of most LLM tech
It has a very interesting license: the source code is public, but the license is restrictive right where all the current ones aren't: it's free so long as you want to make free stuff, but if you want to make money off it, you need to pay.
The license should profoundly upset both the Stallmanite Free Software folks and the ESR/Perensian Open Source folks. Good. They deserve it. They've done nothing to help programmers get paid. Both camps just help megacorps get rich. This is the opposite of their supposed duty.
Congrats and good luck becoming a teacher! I suspect your background will be an asset to your future students who are interested in learning how to code but don't know where to begin.
Being able to type comments inside an actual diff file is starting to feel like a valid and important use case to me.
Yeah... My current thinking is that I want a "rich diff" text format, that shows the diff between base and HEAD, for all files, and includes all comment threads inline. Like, + for added lines, - for deleted lines, c for review comments, maybe r for resolved.
This text format doubles both as a canonical source of truth for the state of the review, as well as the most bare-bones UI. The real UI can then be built on top, either enriching the plain text with LSP (syntax highlighting! Magit style folding! Navigation (I think it's reasonable to assume that you have HEAD and diff opened at the same time)! Code action to add a comment!), or building something fully custom to, eg, show PR as a static web page with rendered markdown.
Though, its a bit unclear to me, what should happen here if the PR branch is rebased, so that both base and HEAD change ... Well, one constraint is that no comment should never get lost, even if it doesnt' attach clearly to the new diff, but beyond that, its fog of war. It probably doesn't make to materialize the rich diff for every PR change, as that's going to get too much duplication. So probably the actual store of data is linked list -- a review contains:
link to HEAD commit
link to base commit
A set of comments on the diff (diff is assumed to be deterministic (which is another design area --- how do you incorporate custom diff algorithms?))
A link to the previous review
So, to get the rich diff, the tool looks at the latest review, computes the diff, then walks the link list and attaches all the comments. Comments from the last batch attach clearly, comment from the previous batches might become orphaned, they are attached heuristically, and, presumably, there's some sort of functionality to go to the review version that introduced the comment?
But then the question, how do you store it? You definitely want to capture, when the PR is merged, the final state of the review, the final base, HEAD, and cumulative set of comments. However, you probably actively don't want to capture the entire history of the review. Imagine
Alice: Why did you commit 4MiB cat picture to your repo, please delete the file?
Bob: Sure, done!
Alice: Sight, you have to force push it, otherwise the blob is still in history?
Bob: 😅, done.
Would be a shame if the file is still pinned by the history!
So perhaps it is the merge commit that materializes the "review diff" in commit message?
All questions are rhetorical, I am basically just thinking aloud here!
I think (or would like to think) the motivations for AI in the 50s and 60s were quite different. Back then, it was common to see a utopian future where robots would do the hard work and people would have a good life with plenty of leisure time (something like in The Jetsons) or other more noble pursuits (e.g. Star Trek). And of course, intellectual curiosity whether it would even be possible to have intelligent machines drove a lot of that (and most AI research was done in academia - although let's be real, likely funded with military applications in mind).
The companies behind "AI" (LLMs, really) in our current era are all transparently about pure profit and total market capture.
he used it as a faster Python that produced easy-to-distribute binaries
I used to be really turned off by Go because of its perceived shortcomings, but after my job required me to learn it and put in the time, I grew to appreciate it. It's a very dull language, with little place to be creative with, but as long as you work with a couple of linters, it's very fast to develop with and you can be reasonably confident in your code.
I do wish tools like staticcheck and errcheck weren't necessary though. For how much Go frames itself as an "unsurprising" language, it does sometimes behave very surprisingly, and it's not fun when some invariant you thought held turns out to not hold.
Looks like you haven’t deployed since mid-2021, so what I was looking at wasn’t exactly what was in the built extension. The preferences page style changes, I prefer it mostly as before. Border isn’t desirable, especially. And when you have a radio button or checkbox in a grid or flex, make sure you don’t use gap between that and the label, or clicks in the gap won’t work properly. Also add <meta name=color-scheme content="light dark">.
Yeah, I'm not sure what's going on with that. I'm not entirely against it due to teacher opsec though. It's just the web interface, the actual ActivityPub endpoints are all fine, so I think you should still be able to follow me by pasting my handle into your client.
One thing I find fascinating is that main stream media never reports favourably about social media.
I think there's been a change there. I distinctly remember the "Arab spring" and other reports (like for instance in reports about China) where social media were lauded as catalysts of revolution and bastions of free speech. So it was definitely portrayed as mostly positive by mainstream media.
This was true until the tide turned and reports came out about the negative effects like election influence by foreign states, the impact on mental health (especially kids) and the general attitude change against Big Tech and "algorithms" (I don't know what's a worse abuse of words, "algorithm" or "hacker").
In all of these, I'm not sure whether it's main stream media was just following popular opinion, or actively shaping it (probably a bit of both), but I'm happy people are starting to wake up to the second order effects of social media.
There's something about the tone of this post (and others like it) that immediately discredits it to me. From the first point:
Truly autonomous and reliable long-horizon agentic software development is so highly improbable using LLMs that it’s essentially science fiction.
The way this sentence is written makes me feel immediately that the author is already very anti-LLM for software. The rest of the points seem to corroborate that, e.g. "In case you were wondering why some of your guardrails are about as reliable as a coin-toss.". Starting with such a strong emotional stance means I'm unlikely to trust what you're about to tell me.
I point this out because I assume the author is making a genuine attempt to change people's minds, and they've gone to all this work to read blog posts and papers and collate actual data, only to lose their intended audience (people who are overexcited about AI) in the first sentence.
Or, maybe it's just intended as a rant. In which case, rant on!
Working on more pixelart for my games and my blog articles, i just published one and lets say, the style i converged on is just walking the line between shitty and funny, see evidence 1 and 2. Both from the same article about ARMv7 emulator improvements. Otherwise at $WORK performance stuff so the customers can actually use the product and in bilbao ill probably visit the start of everyone going crazy for the Aste Nagusia
This is not true at all. Win32 is designed to be language agnostic. Look in windows.h and you'll see pages and pages of typedefs at the top. These are all mapping language-independent type names into C. Many of these have direct equivalents in standard C, but the platform APIs were defined in terms of the language-agnostic types, complete with explicit calling conventions. Pascal and other languages could use these as well with the same localisation.
The higher-level bits of the Windows environment all expose COM interfaces. These are defined in terms of MIDL interfaces. Various tools can take MIDL and generate the interfaces from other languages (C, C++, Rust, Visual Basic, .NET, and so on).
I have my machines send me an email if any systemd services failes, using a global OnFailure unit. Doesn't get simpler than that.
The threat model is the one where software authors are compromised, but would like to pwn you discreetly.
If the software is distributed through your distro's package manager, there's a good chance links to source code are pinned by hash, changes to package build scripts have to pass some review, and each change leaves a paper trail in distro's repos, mailing lists.
If it's just some script passed over https, some guy with enough access rights could replace it for 1h or a day on a weekend, own a few people, and leave no way to prove it happened. Even if a owned user investigates this, they'll have no way of proving that this https server was giving out a malware last Saturday.
The problem with this approach is the everyone does build their own implementation of these ideas and those then don't compose. I've seen C codebases that had to deal with over a dozen (incompatible) string abstractions, for example, because the core language doesn't give you a usable one and every library that wants one implements a subset of the features than a generic one would provide. I've also seen C codebases with multiple incompatible hash tables, where switching a piece of code between them was a major refactoring effort because there was no common interface and their semantics were subtly different.
I disagree on this if you use any of the concurrency features. Go makes data races UB (and will break memory safety on some of them) but provides nothing in the type system to determine whether you've aliased something that you've captured in a goroutines or sent over a channel. There are some linters that catch the obvious bugs, but the fact that objects in Go can be arranged in any arbitrary object graph means that you can't (in the 'not computable' sense) solve this in the general case with static analysis.
But Go as a mostly single-threaded thing, maybe with the occasional goroutine for some background processing in the limited situations where you can reason about ownership of everything the goroutine captures? It's fine. Much simpler than Python, runs faster, trivial to distribute.
Depends on which people. Developers offering curl | sh is low standards and sloppy work. A user running that when the alternative is packaging the software yourself, is understandable.
The main problem of curl | sh is not security, it's that it makes your workstation more of a snowflake server. Those scripts are usually not written with robustness in mind, the degree to which they respect conventions of Linux distros on how to install stuff varies. Is there an uninstaller? Will it work after a dist upgrade? Does it touch things other components depend on? Will it break something today or a month from now?
Enough curl | sh invocations and your machine needs a "Linux reinstall" because too many devs have put too many undocumented artifacts on your system with their unwashed hands. We're not on windows.
An alternative does exist: package your software, do your job instead of making your user's pay for it. Take that switch-case statement in install.sh that checks for user's distro, and write packages for the three distros yous support there. In the age of LLMs, it costs nothing, packaging is specifically that repetitive routine kind of work with no need to do "system design" that LLMs are really good at.
Working, but also being anxious about my career. I won't be too specific as to not sour the mood too much, but the recent developments have me uneasy about the LLMs and our industry as a whole. I'm not necessarily worried I'm gonna be replaced on a technical merit, but on an economical one. More and more companies are drinking the Kool-Aid and it feels like just a matter of time until mine does too and starts buying into the alleged "cost savings" and optimizations. This is a problem because I don't have a degree and my health issues would make it difficult (if not impossible) to perform many other jobs.
In short, I'm going to try and think about possible options if working in tech ends up not being feasible, happy to read any recommendations you might have!
Other than that, I started reading a friend's blog post on adders (ripple carry, carry skip, etc.), and since I lack formal education in that regard, I'm taking my sweet time digesting and understanding it. Started a side project to aid me in that, namely a visualizer where you can put a bunch of different logic gates, connect them with wires and go through the process step by step to better understand it. Sebastian Lague's video is a big inspiration, but I'm not aiming for something as general purpose as that -- I want this toy to satisfy mostly my needs and potentially be helpful to others.
Impressively awful PDF viewer there.
I downloaded and skimmed it. It's very verbose and discursive, in arts/academic style, and I didn't get a lot from it TBH, I'm afraid.
It has not had much "airplay" but the most interesting post-FOSS move I've seen recently is an Android keyboard.
https://keyboard.futo.tech/
It's a multiply-interesting confluence of tech, IMHO.
The license should profoundly upset both the Stallmanite Free Software folks and the ESR/Perensian Open Source folks. Good. They deserve it. They've done nothing to help programmers get paid. Both camps just help megacorps get rich. This is the opposite of their supposed duty.
Congrats and good luck becoming a teacher! I suspect your background will be an asset to your future students who are interested in learning how to code but don't know where to begin.
Or, like, https://heiwiper.com/posts/magit-status-tour/
Or just shoving the text file into your LLM of choice, if that's your thing....
Suggests, offers, but does not require.
Yeah... My current thinking is that I want a "rich diff" text format, that shows the diff between base and HEAD, for all files, and includes all comment threads inline. Like,
+for added lines,-for deleted lines,cfor review comments, mayberfor resolved.This text format doubles both as a canonical source of truth for the state of the review, as well as the most bare-bones UI. The real UI can then be built on top, either enriching the plain text with LSP (syntax highlighting! Magit style folding! Navigation (I think it's reasonable to assume that you have HEAD and diff opened at the same time)! Code action to add a comment!), or building something fully custom to, eg, show PR as a static web page with rendered markdown.
Though, its a bit unclear to me, what should happen here if the PR branch is rebased, so that both base and HEAD change ... Well, one constraint is that no comment should never get lost, even if it doesnt' attach clearly to the new diff, but beyond that, its fog of war. It probably doesn't make to materialize the rich diff for every PR change, as that's going to get too much duplication. So probably the actual store of data is linked list -- a review contains:
So, to get the rich diff, the tool looks at the latest review, computes the diff, then walks the link list and attaches all the comments. Comments from the last batch attach clearly, comment from the previous batches might become orphaned, they are attached heuristically, and, presumably, there's some sort of functionality to go to the review version that introduced the comment?
But then the question, how do you store it? You definitely want to capture, when the PR is merged, the final state of the review, the final base, HEAD, and cumulative set of comments. However, you probably actively don't want to capture the entire history of the review. Imagine
Alice: Why did you commit 4MiB cat picture to your repo, please delete the file?
Bob: Sure, done!
Alice: Sight, you have to force push it, otherwise the blob is still in history?
Bob: 😅, done.
Would be a shame if the file is still pinned by the history!
So perhaps it is the merge commit that materializes the "review diff" in commit message?
All questions are rhetorical, I am basically just thinking aloud here!
I think (or would like to think) the motivations for AI in the 50s and 60s were quite different. Back then, it was common to see a utopian future where robots would do the hard work and people would have a good life with plenty of leisure time (something like in The Jetsons) or other more noble pursuits (e.g. Star Trek). And of course, intellectual curiosity whether it would even be possible to have intelligent machines drove a lot of that (and most AI research was done in academia - although let's be real, likely funded with military applications in mind).
The companies behind "AI" (LLMs, really) in our current era are all transparently about pure profit and total market capture.
I used to be really turned off by Go because of its perceived shortcomings, but after my job required me to learn it and put in the time, I grew to appreciate it. It's a very dull language, with little place to be creative with, but as long as you work with a couple of linters, it's very fast to develop with and you can be reasonably confident in your code.
I do wish tools like staticcheck and errcheck weren't necessary though. For how much Go frames itself as an "unsurprising" language, it does sometimes behave very surprisingly, and it's not fun when some invariant you thought held turns out to not hold.
If you want it—
Looks like you haven’t deployed since mid-2021, so what I was looking at wasn’t exactly what was in the built extension. The preferences page style changes, I prefer it mostly as before. Border isn’t desirable, especially. And when you have a radio button or checkbox in a grid or flex, make sure you don’t use
gapbetween that and the label, or clicks in the gap won’t work properly. Also add<meta name=color-scheme content="light dark">.Yeah, I'm not sure what's going on with that. I'm not entirely against it due to teacher opsec though. It's just the web interface, the actual ActivityPub endpoints are all fine, so I think you should still be able to follow me by pasting my handle into your client.
I think there's been a change there. I distinctly remember the "Arab spring" and other reports (like for instance in reports about China) where social media were lauded as catalysts of revolution and bastions of free speech. So it was definitely portrayed as mostly positive by mainstream media.
This was true until the tide turned and reports came out about the negative effects like election influence by foreign states, the impact on mental health (especially kids) and the general attitude change against Big Tech and "algorithms" (I don't know what's a worse abuse of words, "algorithm" or "hacker").
In all of these, I'm not sure whether it's main stream media was just following popular opinion, or actively shaping it (probably a bit of both), but I'm happy people are starting to wake up to the second order effects of social media.
There's something about the tone of this post (and others like it) that immediately discredits it to me. From the first point:
The way this sentence is written makes me feel immediately that the author is already very anti-LLM for software. The rest of the points seem to corroborate that, e.g. "In case you were wondering why some of your guardrails are about as reliable as a coin-toss.". Starting with such a strong emotional stance means I'm unlikely to trust what you're about to tell me.
I point this out because I assume the author is making a genuine attempt to change people's minds, and they've gone to all this work to read blog posts and papers and collate actual data, only to lose their intended audience (people who are overexcited about AI) in the first sentence.
Or, maybe it's just intended as a rant. In which case, rant on!
Working on more pixelart for my games and my blog articles, i just published one and lets say, the style i converged on is just walking the line between shitty and funny, see evidence 1 and 2. Both from the same article about ARMv7 emulator improvements. Otherwise at $WORK performance stuff so the customers can actually use the product and in bilbao ill probably visit the start of everyone going crazy for the Aste Nagusia
This is not true at all. Win32 is designed to be language agnostic. Look in windows.h and you'll see pages and pages of
typedefs at the top. These are all mapping language-independent type names into C. Many of these have direct equivalents in standard C, but the platform APIs were defined in terms of the language-agnostic types, complete with explicit calling conventions. Pascal and other languages could use these as well with the same localisation.The higher-level bits of the Windows environment all expose COM interfaces. These are defined in terms of MIDL interfaces. Various tools can take MIDL and generate the interfaces from other languages (C, C++, Rust, Visual Basic, .NET, and so on).