14,784 karma · joined March 3, 2013
If I were buying a display for work (which is to say, mostly programming), my choice would probably be the £600 BenQ RD280UG — a 28" 3840x2560 display, which is 4k vertically enlarged to a 3:2 ratio.
£700/£800 buys you a 24" display (with an unspecified refresh rate, so presumably 60Hz), a keyboard, and a mouse. I loved my 27" iMac to pieces, but it's really hard to justify buying this thing today.
A bunch of the complexity comes from having to write both client and server, and the communication protocol between them, then some more comes from the client being responsible for spinning up the server. As with every network service, client/server traffic is the slowest part of the architecture, so a bunch of complexity then comes from having to minimise the amount of network calls (or draw calls, in this case).
Then you hit the part where all of this is performance critical (soft-realtime requirements), so the whole thing is geared towards “writing your own userspace IP stack in C++” rather than “writing a flask application in Python”.
Jokes aside, there is a very definite difference in how my brain "feels" when I'm walking around, camera in hand, looking for things to photograph. It's like I'm in a different "cognitive mode", for the lack of a better term. It's not just about being present and in the moment, but about seeing the world around you from a different perspective.
0. https://drive.google.com/file/d/1tnMlazV0g1syoRPLALJ6576YSYQ...
“Cathedral” refers to development behind closed doors, where you just get a release and a source dump to go with it.
“Bazaar” refers to development done in the open, where you have constant access to the bleeding edge.
At the time of the essay, GCC and Emacs were ESR’s examples of Cathedral-style development, and Linux was the premiere example of the Bazaar style.
The Cathedral style has become a lot less common over the years, but it’s still how e.g. SQLite operates, I think? E.g. Google definitely operates like that with AOSP, but that's arguably more a fruit of them being maliciously compliant with their Open Source promises.
I would argue that, even though it's not my preference, there is real political value in the monarchy today still. E.g. Charles's speech to Congress[0] has a certain weight to it that wouldn't be there if Charles were an elected leader instead of a monarch.
I wouldn't qualify that with "even". Numerical stuff like that is one of Python's most well-developed niches, and Python's numerical ecosystem is the benchmark everything else needs to be compared against.
A bunch of European countries (including all of Scandinavia) are constitutional monarchies, and they don't devolve into the sort of anti-democratic behaviour we're all seeing from Trump. As a UK resident, I would prefer if the UK were a republic on general principle, but I fail to see the monarchy causing any real large-scale harm to society (individuals like Andrew notwithstanding).
The real point they should be making is "no more despots". Some despots are kings, but some are styled presidents, such as Xi Jinping, Vladimir Putin, and Kim Jong Un.
Also, legitimately elected or appointed officials become despots all the time. Hitler had a plurality (but not outright majority) of votes in 1932. Salazar was an MP and minister of finance, and actually legitimately tried to resign from that role several times over many years before he was eventually nominated to the role of prime minister. Ferdinand Marcos won the Philippine presidential election in 1965 with some amount of intimidation, and the Philippines only formally became a military dictatorship under his rule in 1971.
In many ways, that's the scariest scenario — people who legitimately get elected to power, and then use that power to solidify their illegitimate rule.
Given the quality of the output when I ask it to do things I do know how to do, I'm not particularly comfortable with the idea of using AI to do things I don't know how to do myself. It reeks of the Gell-Mann Amnesia Effect.
I have a slightly more nuanced take on it — I use Claude to write Ansible playbooks for my homelab because I know enough about server management to have a clear opinion on how I want things done and why, and enough Ansible that I understand the fundamentals and can recognise (but not write) idiomatic playbooks. That's the perfect storm of getting the LLM to do something I'm not good at, while still being able to judge its output.
use winnow::{Result, ascii::digit1, combinator::separated_pair, prelude::*};
#[derive(Debug, PartialEq)]
struct Roll {
count: u32,
sides: u32,
}
fn number(input: &mut &str) -> Result<u32> {
digit1.try_map(str::parse).parse_next(input)
}
fn roll(input: &mut &str) -> Result<Roll> {
let (count, sides) = separated_pair(number, 'd', number).parse_next(input)?;
Ok(Roll { count, sides })
}
#[cfg(test)]
mod test {
use super::*;
#[test]
fn test_roll() {
let input = &mut "3d6";
assert_eq!(roll(input), Ok(Roll { count: 3, sides: 6 }));
}
}Works like the Black Perl[0] are decidedly artistic in nature. Demos (in the demo scene sense) are an artistic endeavour. Competitions like the Obfuscated C Contest or the Underhanded C Contest are very much judged on aesthetics.
I understand why you'd want it, and that's why RFC10008 introduces QUERY as a GET-with-body alternative.
A bit tangential, but I really *really* appreciate them making this distinction, and wish more people did this. Way too many tools try to advertise themselves as all things for all people, catering to all use cases, and that helps nobody.
"Slop" just means something is low-quality and of poor craftsmanship, irrespective of who or what made it. If it's slop, you don't need to look for tells, you can just tell it's slop. Sure, AI is prone to specific types of mistakes, and humans are prone to other types of mistakes, and you can often tell whether a specific poorly-crafted UI is man-made or machine-made, but bad is bad is bad.
Both are true. The board as a whole is his boss in his role as CEO. He is the board's boss in his role as majority shareholder. That makes the situation a little less clear.
We've gone from completely dumb eccentric rotating mass vibration to trackpads that you'd swear are actually physically clicking, or the Ice Cubes demo in in Nintendo's 1-2-Switch[0], both of which use linear resonant actuators. Those actuators are themselves a complex enough piece of technology to warrant a patent, and the techniques to simulate the feel or real physical objects using those actuators are pretty damn non-trivial as well.
As a general rule, I find that the patent system is problematic but, within the scope of the system as it exists today, these are perfectly reasonable things to patent.
Now, if you want to argue that the difference between a dev board and an SBC is kind of vague, I agree on that front. I'd argue that the distinction is mostly the vendor's intent. E.g. if I sell the ICs in bulk and _also_ sell a board with that IC, it's probably a dev board. If I source the ICs from somebody else, only sell the assembled boards, and ship a general-purpose OS with it, it's probably an SBC. With sufficiently powerful hardware (like this thing seems to be), you could use a dev board as an SBC, and that is basically what this article is all about.
As for the only difference being the file name, that's an untested assumption. Up until now, Claude hadn't supported AGENTS.md, and it's a simple application of Hyrum's Law that somebody, somewhere, was taking advantage of that to give one set of instructions to Claude, and a different set of instructions to some other provider. The correct behaviour in the presence of both files is not obvious, either.
Having a kill switch for the change is a perfectly reasonable safety measure in case something goes horribly wrong.
If you have kids, "Screen Time" is a reasonable enough name for the place where parental controls live.
If you work under the assumption that AI features are OK in general, but potentially problematic around kids in particular, parental controls are a reasonable enough place to put these AI controls.
If you're not a parent, and have broader concerns about AI, you'd never even think of looking for these options where they are.
This distinction doesn't change what the performance numbers look like today, but it does inform what changes would be necessary for those numbers to look different tomorrow. E.g. Apple Silicon isn't fundamentally orders of magnitude more efficient than x86, they just used smaller features. Newer Intel and AMD chips made on equivalent processes _also_ get similar efficiency gains.
The problem, of course, is that having only the one single "you can't win" law is severely underspecified, but the solution was too clever by half, and highlights the problem with this approach — every program will be under-specified, because, at some point, writing the laws becomes a bigger problem than writing the code itself.
This becomes a real issue because the combination of underspecified but rigid laws pushes the aI towards this sort of "creative" solution that matches the letter but not spirit of the law. In this case, the issue was obvious, but I seriously worry about what sort of shenanigans will occur in less obvious cases.
In fact, their own documentation spells this out specifically[0]:
> The Steam DRM wrapper by itself is not an anti-piracy solution. The Steam DRM wrapper protects against extremely casual piracy (i.e. copying all game files to another computer) and has some obfuscation, but it is easily removed by a motivated attacker.