Well, as long as the step rate remains well above the Nyquist limit? Otherwise, your simulation will start to have something akin to aliasing errors.
That is one place where an analytical solution is a benefit, even if it is a bit less realistic. You just have a position(t) parametric function you can evaluate when rendering sporadically.
> There is a really important question that is been lost between the anti and pro AI camps which is really answering what AI is good at and what AI is bad at, ...
I think some of this pro/anti AI discussion is really a proxy for something else though. There is another unstated, societal disagreement about personal responsibility and the behaviors of the AI tool users.
It isn't entirely new, as people have always been blaming abstractions which lack agency (society, bureaucracy, "the machine", "the process", "the game", etc.) to conduct themselves in an ethically or logically flawed manner and then shirk responsibility. But, I think it is accelerating dramatically with the way AI agent usage is being adopted. I don't see how this can possibly continue to be normalized without leading to a catastrophic outcome.
Right now, AI tool usage is being applied in ways that would have been considered misconduct, negligence, or fraud if the actors were doing the same thing via traditional outsourcing. People who have a contractual and ethical responsibility to apply analysis, judgement, and oversight are rapidly turning into dumb pipes who just relay content. They essentially phone it in, trying to take credit for apparently moving KPIs "up and to the right". They pretend to themselves and others that they are reviewers and still in control, but when things go wrong they expect forgiveness and for others to lean in and clean up their rapidly spreading mess.
In software circles, many of us are appalled by this slop that is poisoning the well for our existing organizations. It seems like a massive, toxic externality. To us, people aiming their AI agents into our existing collaborations are pretty much flipping a switch to "roll coal", or worse.
I don't know if that's specific to AI. It seems accountability levels are in hell right now. Consider anything the president has done and how that would have gone if any other president ever did it. Or anything AI companies do. Or anything Tesla does. Or X.
Hah, maybe its the difference between why as in "this addresses problem X" and why as in "because those jerks in pre-sales sold another imaginary product"
I think the commit ought to describe the purpose of the change in terms of its result for the software's intended use. Feel free to hide the business/political drama behind a ticket number.
This gets down to a more fundamental tension. Are commit messages to communicate between developers? To communicate from developer to consumer? Or some kind of project manager golem? In practice, it is usually some constantly wandering attempt to be a blend of these.
The last part is easy to answer. Commit messages are solely for developers IMHO. The communication between developer and customer / product manager should be via the ticket system.
That said, knowing the commit ID something is fixed in, so that the PM can track what build it emerges in is useful.
It's a fascinating question. I took the GPP as "media literacy" as more of an elite culture shibboleth. Making the right references in this sort of elitist signalling process is more about showing alignment to your contemporaries. It is just as much making the right references and omitting other references.
Being an LLM that "knows a bit of everything" doesn't necessarily give you access to know the audience expectations in this sort of environment. They are layers of fashion and social context which almost intrinsically embodied as a fringe of temporal currency and connection, not necessarily available in any training corpus.
An LLM could be stuck in some imposter/savant moat here, always making last year's references or possibly over or under selling the current expectation.
I guess most would probably assume at least one epic refresh where there wasn't really anything carried across except maybe the parking spot on your desk. And since the 486 era, most probably expect your desk and/or physical site changed too.
There were so many potential PC era boundaries like case and motherboard form factors, external peripheral buses, HDD controller types, expansion card buses, cooling and PSU demands, socket/RAM formats, display types, and display connection types, ...
So many opportunities to think, "this seems like a time for a clean slate." If for no other reason than to bring up the new computer and have the old continue in transition or as some kind of spare, backup, or hand-me-down.
> There were so many potential PC era boundaries like case and motherboard form factors
Only one change really from AT/Baby AT to ATX. We've been on ATX now for 30 years. I could grab an A-Bit BH6 motherboard from 1998 and put it in my modern Hyte Y60 case if I wanted to.
> external peripheral buses
Since we're talking starting from 486 era, that only means going from PS/2 to USB for keyboard/mouse, parallel port for your printer, maybe serial port for a modem. During the transition period, adapters were cheap and common.
I don't know about the ESDI to IDE transition, but I know from IDE/PATA to SATA there was a period where motherboards had both. During the transition from VGA to DVI, then DVI to DisplayPort, GPUs had both.
> cooling and PSU demands
If you overbuy on the PSU a little, you can get a ton of futureproofing. CPUs came with stock coolers until just a few years ago.
> socket/RAM formats
Which is why the CPU/mobo/RAM upgrade was typically done as a trifecta.
> So many opportunities to think, "this seems like a time for a clean slate."
Never felt the need. As mentioned above, there was frequently a transition period for when hardware supported both old and new tech.
Yeah, I guess I have a longer view since our first IBM compatible PC was a 286 based XT form factor. And in households with multiple computer users, upgrades could look more like mitosis (or nuclear decay?), with some parts splitting off to form new computers and less clear lineage of one computer just mutating.
The buses I was thinking of included ISA, EISA, VLB, PCI, PCIe. Yes there were ways to carry some things across since motherboards often had a couple bus types at once. But in my experience, the older peripheral cards often just got retired as they became either obsolete concepts or totally integrated in the next motherboard. I.e. you once commonly had serial port and parallel port expansion cards, game controller cards, sound cards, disk controller cards, and basic 2D graphics cards.
Cases also got smaller because the motherboards needed less space, people needed fewer expansion cards, and also because people needed fewer and fewer "drive bays". In the early days, you saw both 5.25" and 3.5" floppy drives, CD-ROM drives, big chunky HDDs, and possibly other weird removable media drives. Now you can easily have a capable corporate-style PC with no expansion cards, and no drives other than the M.2 stuck into the motherboard.
On the external side, I can think of PS/2, serial, parallel, USB, external SCSI, Firewire, e-SATA. Some of these coexisted with USB until it became high speed enough to subsume them. With graphics there was VGA, composite video, DVI, DisplayPort. Sound had 3.5mm, coax, toslink, coax digital. Communications commonly had POTS modem, coax ethernet, twisted pair ethernet. Somewhat esoteric were WiFi and bluetooth adapters. These could be on dedicated expansion cards, integrated into sound/graphics/comms cards, or integrated into the motherboard.
There were also weird expansion cards that paired with a particular external device, like a scanner or Hercules monochrome monitor. And more unusual cards like video-capture and digital TV or radio tuners.
The PSU issue wasn't just overall wattage but different set or balance of voltage rails and kinds of internal connectors needed for powered components. And shifts like standby power/soft-off behaviors.
I also recall AT to ATX and later uATX. Earlier motherboards were massive with socketed DRAM and SRAM chips and lots of simpler logic chips all over. They just kept shrinking as everything got more highly integrated. If you ever got a surplus Dell you might have encountered BTX too, which was like the left-handed universe.
I also had a phase with two uATX cases and almost had a "two space garbage collection" upgrade cycle, shifting parts in, between them, and out. One was my desktop PC and the other a "media PC" attached to TV and home stereo.
Some folks like me had a phase of trying to accelerate the down-sizing, abandoning our ATX/uATX for things like the Shuttle XPC mini/bookshelf computer formats. This meant more incompatible chassis, motherboard, and PSU formats. For me, a computer after 2000 was case/PSU + mobo/CPU/RAM + disk. The disk was either a single HDD/SSD or small software RAID array. At one time, we needed multiple disks for capacity, but now it can just be one or two M.2 drives on the motherboard and no disk bays at all.
This also leads to periodically thinking just a laptop will suffice, and then that becomes another thing that sees little upgrade and carry forward over longer time periods...
> Yeah, I guess I have a longer view since our first IBM compatible PC was a 286 based XT form factor.
The first time I used a PC was an Amiga in 1989. As my username implies, I was only 7 years old at the time.
My first IBM-compatible PC was a 486, I think in 1993. My dad got a used one and bought some multimedia kit that included a CD-ROM drive and audio card (Likely Sound Blaster, or at the very least, Sound Blaster compatible). Played a bunch of Stellar 7 and King's Quest, but also got into DOOM and Master of Orion.
That 486 was the start of the Ship of Theseus PC, though I didn't play a part in replacing parts until 1999 when I was 17 and bought a new hard drive with the money from my first job. Until then, my dad did the upgrades, but I always watched with great interest.
> Some folks like me had a phase of trying to accelerate the down-sizing, abandoning our ATX/uATX for things like the Shuttle XPC mini/bookshelf computer formats.
The tiny form factors like uATX and ITX never really interested me. Even when I started going to LAN events, I preferred a normal sized PC, even though my current rig probably weighs like 30-35 lbs. My GPU alone is like 3 lbs, and the Hyte Y60 case is 21 lbs empty.
> This also leads to periodically thinking just a laptop will suffice
I could never. My demands for being able to upgrade, not to mention to have something aesthetically pleasing, are too much for a laptop. I don't even have a laptop for casual use.
I was running Linux on my 386 in college in '93. And within a year or so I had upgraded it to 486DX3 and had a DEC Alpha alongside it also running Linux, with the two connected by ethernet.
I haven't bought a discrete graphics card since those days and it was an XGA compatible 2D accelerator. Every 3D card I've used has been in a work machine. At home, I've always used iGPU solutions with my AMD Ryzen laptop being my most powerful. And I had more than one phase where a Thinkpad was all I had as we moved around.
Instead of graphcics, I went crazy with HDD arrays at times. Software RAID with 3-5 disks was the most cost effective and reliable way to do bulk storage for a time period before huge HDDs and SSDs were affordable. I even built a 10 disk mini tower PC for a family member who was obsessed with recording broadcast TV via MythTV.
Hah, yes, I have stuck to relatively classic 2.5D and 3D games that work on current iGPUs. It's nearly a nostalgia thing since I met Doom in college.
I struggle with the gaming hardware ROI, when I see how things become obsolete. E.g. my work bought me a Titan-X in 2015 for numerical/image processing work. Ten years later my Ryzen 7840u had nearly the same GFLOPs, though of course with less memory bandwidth. It also does it with vastly less heat/noise.
I know I would enjoy immersive VR. But I don't hink I would use it often enough to justify all that dedicated gear and the computer strong enough to drive it.
> I struggle with the gaming hardware ROI, when I see how things become obsolete. E.g. my work bought me a Titan-X in 2015 for numerical/image processing work. Ten years later my Ryzen 7840u had nearly the same GFLOPs,
10 years is an eternity in computer hardware. The idea that you should be able to get 7+ years from your hardware is a more recent thing. Imagine comparing the 2.8 Ghz Pentium 4 you could get in 2002 with the 66 Mhz 486 that was state-of-the-art in 1993.
It used to be that processor speeds were literally doubling every ~18 months. The computer you bought to run Windows 95 would have choked on Windows XP 6 years later.
Hardware ROI has gotten better in terms of how long you can use a system. Just look at how many people on HN talk about using 10 year old hardware for both productivity and gaming. I've got a 5090, sure, but that's mainly because of wanting to play MS Flight Simulator 2024 and Cyberpunk 2077 with all the details cranked in 4K at 240 fps, and wanting enough VRAM to do local models. If I was okay with lower detail settings in 1080p at 60 fps, I could get by with even a 9 year old 1080 Ti.
Meanwhile, imagine trying to use a computer from 1992 in 2001 as Windows XP is dropping.
EDIT:
> I know I would enjoy immersive VR. But I don't hink I would use it often enough to justify all that dedicated gear and the computer strong enough to drive it.
It takes surprisingly little to enjoy VR. I think most games are written for the Quest 3 which isn't all that powerful, and then ported to PC with the same graphical fidelity. When I first got a VR headset, I was on a GTX 1070 and it played Beat Saber at the 90 fps that my headset did just fine.
I was well aware of the progress rates. But, not being tied to Windows, I have a different perspective on computer utility. As a kid, I used word processors and games on CP/M, Amiga, Apple II, and DOS before Windows 3.0, and then I got into Linux and stayed there. Basic "productivity" was always possible in my view, whether we're talking WordStar, WordPerfect, MacWrite, MS Word, AMI Pro, Libre Office, or the current cloud document editors.
I encountered subsequent Windows and Mac versions in work environments, but mostly kept them at arms length. I didn't embed myself the different Windows or Mac eras. Instead, I always had the same baseline, internet-connected machine experience with a similar environment of CLI, Emacs, X Windows, C programming, shell, Python, and other scripting languages like Scheme and Common LISP. The web arrived with Mosaic and evolved long with the content. Things like FTP sites, gopher, and USENET fell by the wayside.
But, the entire hardware history with Linux was a lot more incremental, overlapping, or blurry as far as different capabilities or needs. E.g. SMP, multi-core, large files, 3D acceleration, 64 bit, high speed networks, LCD monitors and associated video output formats. You could chase these different bits to your heart's content, but could also run for a long time with the same basic kit.
Due to CS in college and my career, I always had exposure to a range of IP networking technologies. My work computers were connected to the internet via ethernet and quite high speed WAN uplinks, while home went through the sequence of POTS, ISDN, ADSL, and cable modem. I was using Linux on Laptops, and we had WiFi at work since its very early days around 1997. We were also early adopters of 1000-BaseT in the LAN, so I remember the days when our data transfers were often limited by computer speed rather than trivially saturating the link.
To me, the increases in RAM and disk space over those decades were the most notable. I could do the same kinds of algorithmic work, but data sizes could be bigger. You can often let a program run longer, but a limited working-set size is a fundamental issue.
Of course, there were commensurate speed increases to make practical use of that extra space. I.e. how long does it take to transmit, store, and process these larger data that would exploit it? The realtime threshold brings associated eras. When was it practical to record/store/playback WAV audio, MP3, MPEG video, etc.
I'm old enough to have visually parsed the headline as "PC speaker" at first, and wondered what kind of amazing phreaking was going to drive the built-in speaker as a microphone and somehow get ingress into the computer. :-)
Yeah the headline isn't as interesting when truthful. I've never owned a "speaker" that plugs into USB. Only the good old analog audio jack, or a USB to toslink adapter that is purely a one-way stream.
Are you saying that a "hybrid KEM" is different in theoretical risk from chaining two KEMs? The change of jargon from "encryption" to "KEM" doesn't mean anything to most people talking about this post-quantum risk. To the extent we know what KEM is, we think it is just encrypting the key used for the rest of the bulk encryption.
Whether or not people understand the nuance of encrypting the block cipher keys or encrypting the blocks themselves, I think we all mean to stack the two encryption methods for defense-in-depth protection. They intuit having to open two locks in series to get to the valuable stuff, not adding two different access paths that each suffice for access.
"Intuition" about how cryptography works is notoriously bad. Many intuitive things about cryptography are false, and many true things about cryptography are non-intuitive. For this reason it is difficult to seriously discuss cryptography when people are vaguely referring to what they intuitively hope to achieve, framed in terms of concrete constructions that are not secure.
This is also completely ignoring that designing secure systems is about MUCH more than selecting the right "hard problem". Concretely
> They intuit having to open two locks in series to get to the valuable stuff, not adding two different access paths that each suffice for access.
might mean requiring a much more complicated lock that, in its ideal implementation has the properties you want, but practically is easier to implement incorrectly, yielding a less secure scheme. Considerations of this form almost never appear, despite being very relevant to the end goal of protecting users.
Similarly, this "defense in depth" intuition is currently not particularly controversial for hybrid KEMs. it is currently quite controversial for hybrid signatures though. The intuitive story would work perfectly well for signatures though. So this intuition does not end up being particularly useful for understanding the actual discussion.
I don't disagree, but I think the folks who know this ought to remember the lay person perspective and try to address it more concretely.
Rather than rejecting the framing because they (we) aren't fluent in your jargon, provide a more constructive hint... E.g. "You may be thinking the symmetric cipher key is simply encrypted with the asymmetric cipher and concatenated to the bulk message. But, to mitigate known cryptographic system risks, modern solutions use specialized key encapsulation or key exchange methods (KEM) which are not directly encrypted messages containing key material."
> I think the folks who know this ought to remember the lay person perspective
That's fair. I hold Hacker News to a higher bar of technical proficiency than a general audience. My hope with insisting on correct framing is to nudge other experts in adjacent fields to teach your more general audiences how to think about these topics more correctly so it's more approachable to the general public.
I'm generally sympathetic to your point, it is just difficult for this particular topic. For example, I mentioned how precision in cryptographic language is important, as there was a discussion about combiners for encryption, when really people should use combiners for KEMs, along with hybrid encryption (here, meaning building public-key encryption from a KEM + symmetric key encryption).
The issue is that none of the above is relevant to the article that we are in the comments of. The article is about signatures. Why are we talking about encryption/KEMs in the first place?
One might hope the story for combiners for KEMs (which people may have intuition for due to combiners for encryption, which you could easily show in an undergraduate cryptography course) is broadly similar to the story for combiners for signatures. Unfortunately, that's not true at all. It would be a very reasonable perspective to have that we should use combiners for KEMs but not combiners for signatures. It would be very difficult to communicate this to a layperson without being very precise about the jargon.
This is especially true as this is a topic where a notable cryptographer has spent the last few years libeling several other cryptographers, and spreading a good deal of misinformation to laypeople. He is also extremely litigious, and has either sued or threatened to sue several cryptographers for what I view to be nonsense reasons. For some (at least myself), this makes precise language all the more important in topics he might have his eyes on.
So I both broadly agree with you for most topics, and also this particular topic requires a good deal more precision than most others in cryptography.
> Are you saying that a "hybrid KEM" is different in theoretical risk from chaining two KEMs?
No, I'm saying that "hybrid KEM" or "chaining two KEMs" is very distinct from "encrypt twice". Confuse the two at your own peril.
> To the extent we know what KEM is, we think it is just encrypting the key used for the rest of the bulk encryption.
Encryption is reversible. If you have the key, you can decrypt. It's not encryption if you can't decrypt.
KEMs are their own class of algorithms. They combine an asymmetric encryption scheme with an all-or-nothing one-way transform (usually a key derivation function built on hash functions). It's the safest way to hold asymmetric encryption in practice (even not considering PQ; RSA-KEM beats RSA-OAEP in implementation safety).
Calling KEMs "encryption" is misleading to the point of malpractice. I will push back on conflating the two.
> Whether or not people understand the nuance of encrypting the block cipher keys or encrypting the blocks themselves, I think we all mean to stack the two encryption methods for defense-in-depth protection.
Your only defense-in-depth should be in delivering a strong pseudorandom ephemeral key over an untrusted network, and then using the tried-and-true AEAD constructions that we're already using today. Encrypt once. Do whatever you need to do to get the key exchanged securely.
I write a blog that very regularly covers applied cryptography. I deal with newbie confusion all the time. It's very important that we talk about these things correctly on forums like Hacker News comment threads so that the people learning from us won't get more confused.
That is one place where an analytical solution is a benefit, even if it is a bit less realistic. You just have a position(t) parametric function you can evaluate when rendering sporadically.
reply