Hacker Newsnew | past | comments | ask | show | jobs | submit | gecko's commentslogin

My favorite alt time is definitely the ancient way of doing things: there are twelve hours during the day, and twelve hours during the night. Yes, this means that the length of an hour at night is different from the length of an hour during the day (at least most of the year). This system is still used in some oddball places (like certain aspects of Jewish religious law, and possibly Islamic law as well for all I know), but, having written such a clock once, I did kind of like that you could get a feel for where you were in the year purely based on how fast the second hand was ticking during which half of the day.


Japan kept up with a system like this until the early Meiji period (1870s). As you can imagine, it led to some interesting mechanical clock designs.

https://en.wikipedia.org/wiki/Japanese_clock


I will say that a lot of that RAM is going to creature comforts that aren't about apps getting worse per se. For example, everything is running double buffered images and windows in HiDPI. The era you're talking about, applications were in charge of redrawing their window whenever you exposed their contents/tabbed back to them/etc. If they genuinely needed double buffering, they'd need to do it themselves, so apps rarely did. Plus side, less RAM, downside, you would get gray nondescript windows and redraw errors when moving and resizing windows. Nowadays, Windows/macOS/Linux instead keep double- (or even triple-) buffered copies of all that. Throw on all the HiDPI images and whatnot, and you've already used up more RAM just on that one thing than the old apps used to take. But you can tab between apps with full previews, and you don't get gray blobs and tearing when an app is overloaded. Other things, like 64-bit pointers, or static linking becoming a common way to deal with DLL hell (sigh), also add RAM, but are also solving real problems.

I'm not really defending all those decisions or anything, beyond that it's not simply a case of lazy devs or whatnot. We made trade-offs as a community that genuinely improved the user experience. I may not agree with all of them, but I get why they happened, and don't spend a lot of time wondering why we used to need fewer resources.


HiDPI isn't really a significant factor. Electron apps still use crazy amounts of RAM in 1080p. Same for double buffering I would assume.


I read comments like this and I wonder “how do you know Al, this in enough detail to explain it so simply? What was your path from DSA1 to this? Or maybe happened earlier? Was it a thing of the times? Sometimes I with I was not a kid in the 90s or before to absorb the rawness of computing that must be so useful and unique to have today.

I say this and at the same time I feel like it must be rare in today’s ultra competitive and optimized software world to admit this sort of thing, am I alone? Am I the only ignorant?


I was always under the assumption that application windows were all rendered as separate layers on the GPU and the artifacts on older Windowsen were related to pre-GPU UI rendering.

So rather than occupying main RAM they’re on the GPU RAM and main RAM just orchestrates.


Uh, that title is...wrong...


I was super excited to see this comment, but I don't seem to have those cmdlets, even though I'm on Windows 11, fully updated. Are you sure you didn't install something extra?


If I recall correctly, they only work in PowerShell 7. If you don’t even have them in there, you can install them from https://github.com/microsoft/winget-cli (which is bad UX, but if you just need them on one system it’s a way to do it).


I'm in PowerShell 7.4.2 and they're definitely absent. I hadn't thought to install directly from GitHub, given part of the whole shtick of winget is it's The One True Package Manager and bundled, but I can't say I'm surprised, either...


Probably better off installing from PowerShell Gallery instead. https://www.powershellgallery.com/packages/Microsoft.WinGet....


I don't remember. Maybe I did install the modules. https://www.powershellgallery.com/packages/Microsoft.WinGet....

    Install-Module -Name Microsoft.WinGet.Client


I mean, it is a country of laws. Just...some of those laws are pretty bad. For what it's worth, the Court in this case is narrowly focused on correcting a lower court's interpretation of the Copyright Act, not something in the Constitution or something fundamental, and on a first glance, I at least feel that their conclusion is highly justifiable. That doesn't mean the Copyright Act isn't fundamentally broken (it is, on my opinion), but that's trivially fixable by Congress if we get appropriately minded representatives.


The doctrine of adverse possession is well-established, at some point there has to be certainty about who owns what. Look at East Germany after reunification if you don't believe, the fights over real estate seriously delayed rebuilding.

But for copyright adverse possession doesn't apply - it's understandable why the music industry would have the Court say so.


I'm not sure you understand how WSL works: it's just the native `curl` binary for whatever Linux distro you're using in WSL. On both Ubuntu and OpenSuSE, which are the two I have installed, --cacerts works as expected, because of course it does.

Separately, Microsoft bundles curl.exe as part of Windows since somewhere in the later Windows 10 or early Windows 11 releases, I forget which. This also appears to be honoring --cacerts.

So no, this seems to very much be an Apple problem.


I love the concept of Fossil being in SQLite, but there's a reason that Mercurial invented revlogs and Git tries to keep related objects close to each other in packfiles. Sometimes, you really do need a dedicated file format optimized for specific use cases. I'm completely unsurprised OpenBSD wasn't able to pull this off.

(Kiln split the difference by storing metadata in SQL Server, but keeping all the actual source data in their native formats. This works great, but is only really viable if you can guarantee things never get out of sync, which is basically impossible for random local Git repos.)


Isn't that literally just slightly different colors? I don't remember meaningful differences between OS/2 1.3 and the Windows 3 line. I always thought that was part of why WinOS2 worked well: the Win32 apps looked like the old OS/2 apps, both giving them familiarity and emphasizing they were old.


I was curious about this and looked it up for anyone else who wants to see too: https://www.os2museum.com/wp/os2-history/os2-1-2-and-1-3/

I never used OS/2 and most of what I’ve seen were from the final versions, so I had no idea it basically looked like Windows 3.x in the earliest versions.


It's the other way around. Windows 3.x looked like OS/2 1.x


The window borders were grey rather than black. That made a huge difference in the subtleness of the contours. The resizable borders were a bit thinner, IIRC (could be the grey outlines though.

I need to play with it for a while.


It hasn't changed radically, but it has changed. Wikipedia actually has a nice write-up if you want the details, but support for symbolic links, transactions, and partition resizing are all things that have materially improved my life in the last ~5-10 years.


All of those features are over 10 years old. Time moves fast. Windows 7 was 14 years ago.


> Windows 7 was 14 years ago.

Surely you lie..


And here I am, still trying to rid the corporation from Office 2010 from some users..


Unfortunately(?), Transactional NTFS is deprecated and Microsoft claims it may not be available in future versions of Windows.


It'll reset the engine control unit (ECU), which will cause your car to run rough constantly as the computer has to relearn how to adjust the engine tuning from scratch every drive. You'd be better served using a trickle charger.


Resetting the ECU will also cause the vehicle to fail inspection unless it's driven long enough beforehand. (Here in Upstate NY, anyway)


that is not how ECUs function Some Transmission Controllers will adjust to driver behavior, however engine controller default behavior shouldn't cause 'rough' experience I worked in automotive testing for over 10 years and constantly measured and analyzed vibration data on vehicles. Many prototype vehicle batteries die due to early release software that causes parasitic drain and I have never noticed any rough behavior just because the battery died and got replaced. There are many sensors and closed loop control systems that monitor strange engine behavior and adjust timing. This happens very quickly within few engine rotations. If there was an issue you would notice it for at the most for couple of seconds.


Yes, it's a closed loop. The O2 sensor in the exhaust rapidly adjusts the mixture.

The whole 'learning' the air fuel mixture to adjust the stoichiometric ratio over a longer period of time does not make any sense. You have the air mass, O2, fuel, temperature and sometimes more, you can calculate the mixture near instantly.

Maybe someone way back said you have to warm the car up and that takes a few minutes. Modern fuel maps achieve a fair idle from near dead cold. It's a solved problem.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: