Hacker News Reader

Comment by xroche | Hacker News Reader

As a rule of thumb, you have:

  * Decent software companies terrible at making hardware
  * Decent hardware companies terrible at making software

I yet have to see one that does both correctly. Hardware manufacturers are known to produce the worst code quality you can think of, badly designed, poorly written, undocumented, insecure, bloated.

I have the feeling that the whole IoT problem is also related.

View on HN

> Decent software companies terrible at making hardware

Not sure if one wants to count them as a decent software company, but Microsoft is quite good at building keyboards, IMHO.

Their internal divisions might be all over the place regarding company policies (see: Windows 10 as spyware :) ) and their insistence on keeping strict backwards compatibility with sub-par products (DOS, basically) might be debatable.

But their engineering these days is top notch. They might not be the best but they're probably in the top 10% sofware companies regarding engineering practices, IMO. If not higher.

> and their insistence on keeping strict backwards compatibility with sub-par products (DOS, basically) might be debatable.

All 64 bit versions of Windows can neither run DOS applications nor Win16 applications (I described the technical reason for this at https://news.ycombinator.com/item?id=14246521).

While that's strictly true, there's a wider range of backwards compatibility they're keeping.

See the whole Rust/Cargo problem on Windows. Windows files can't be named con, aux, etc., because the Windows file systems are backwards compatible, generationally, all the way to DOS, which didn't have subfolders initially and which reserved those keywords for special files. Then as DOS added subfolders it still kept that global restriction, then Windows adopted it... and here we are today.

Windows is full of these things, a lot of them coming from DOS and more coming from Win16 or even early Win32.

I know they broke backwards compatibility in the strict sense with Win64, but apart from this not many situations where they did it come to mind. And even for that, they only did it because the overall market for DOS/Win16 was tiny at the point when they did it.

POSIX and its ecosystem is also full of this backwards compatibility baggage (I for example claim that X11 has a lot more outdated backward compatibility legacy than WinAPI - no surprise since it is much older). Just to give a few basic texts about this:

The Unix-Haters Handbook: http://web.mit.edu/~simsong/www/ugh.pdf

A Tale of Two Standards: A text by a person (Jeremy Allison) who understands both WinAPI and POSIX: https://www.samba.org/samba/news/articles/low_point/tale_two...

The reason why people tell this all the time with respect to Windows, but much more rarely with respect to POSIX and its ecosystem, is in my opinion that much more programmers have inhaled the latter.

Concurrently occurring Creation -> Obsolescence produces overlap:

   DOS    Win3.1        Win95                Win10
  
   Creat.             Obsc.
   |---------App----------|
       |---App---|
                     |-----App-----|
  ~1980=========================================~2020
     |-----App-----|
             |-------App-------|
                            |--------App-------->

(Okay, that looked a little better in my text editor.)

Vista (or was it XP) introduced a new security model that made prior apps that depended on a common install location being writable very interesting... They still kind of worked, but data's actual location was then per-user.

Other than that, most windows software runs as it has for a fairly long time now.

CON is even older - it came to DOS from CP/M!

I'm pretty sure that excuse is random bullshit.

First, are handles limited to 16 bits in 32-bits Windows? I'm pretty sure they are not, especially when the 2 lsb are 0 for NT handles...

Second, you could cherry-pick other random resource pointer and make up another excuse with the same power: e.g. "32-bits programs can not work under 64-bits Windows because pointers are 64-bits wide with 'all' (at least > 32) their bits used, so they won't fit in 32-bits pointers of 32-bits programs"

That's not how retro-compatibility involving virtualization is engineered - that's pretty much the other way around! If MS wanted to make Win16 run on 64-bits Windows, they could have engineered it (without much difficulty). They choose not to (and I don't blame them too much for that) and as a result, maybe some (or a lot) of details that would have been needed to ease that implementation do not exist (maybe SOME handles were limited to 16-bits on 32-bits Windows, all the time or when the program was a 16-bits one - and the provision to limit to 16-bits is not there anymore in 64-bits Windows as a result of the lack of purpose it would have given the general lack of support of win16 on this plateform), which maybe makes it harder to do for a 3rd party now... (and even by MS, given Windows has evolved a lot since introduction of 64-bits)

If you really have 16-bit windows/dos software, these days dosemu or WINE may be better options under a VM (Not sure if ReactOS would work well enough). DosBox may work as well, depending on specific needs.

Regarding compatibility.. didn't they try to break away with Windows N? Though a commercial flop, only available on ARM and locked down devices... I hd pretty high hopes in that space, higher that they'd take Server in that direction...

I'm not sure MS can really dead-end a legacy codebase so easily. They seem to be trying, but hitting resistance at every turn.

I disagree. Every Microsoft Natural keyboard I've used that's more than a few years old has gotten incredibly mushy. I make an exception for the original line of Natural Keyboards in the mid-1990s that had a firmer membrane, but the current range, including the "Ergonomic Keyboard 4000" just feels like I'm typing on kitchen sponges.

Sad to hear that. I like the 4000, in fact I am typing on one right now.

I vaguely remember Fujitsu had an ergonomic keyboard (one could even adjust the angle between the two halves), but I have never laid hands on it, so I cannot say anything about the quality. All Fujitsu notebooks I have touched had absolutely crappy keyboards, but that might not mean much.

I've never had a 4000 that survived more than a couple of years. Inevitably one of the keys gives out, and then it's off to Office Depot to buy another one.

The main thing it's got going for it is the overall layout, which is fantastic. If someone made a keyboard using mechanical switches with the same layout I'd snap it up in a hot second. But for reasons unknown, while keyboards with mechanical switches have proliferated in recent years, none of them incorporate 4000-style ergonomic features like split keys or a curved key bed.

The driver for my Microsoft Designer Mouse (one of their latest models) stopped working when I updated windows the other day, no word on when a fix will occur.

Microsoft hardware in general has always been very good IME. Their mice were the best around for decades, and I'm loving my Surface Book.

Keep in mind Surface Books don't have global support - I bought mind in at a Microsoft Store in the US and Microsoft UK just won't look at it.

comfort curve 2000/3000 are one of my fav to work on.

comfortable without the annoyances of going full mechanical.

also their optical mouse is quite good.

but the real crown jewel was the xbox steering wheel (the real one not the U stick): solid, precise, feature packed and sold at an incredible price.

I agree. My main keyboard is a Microsoft Internet Keyboard that I have been using for many hours daily since 1999, surviving five different computers (all running Linux). It's the most comfortable keyboard I've ever used, and it shows no signs of wear other than having some stains, plus partial fading of a few of the key symbols, and the Ctrl and C keys are beginning to show dents where my nails have been hitting them.

There are no good standard rubber dome keyboards. Try using a keyboard with real switches or good rubber dome like buckling springs or Topre switches and you'll know what I mean.

Old 1990s hardware from them was awesome. IntelliMouse, Joysticks, keyboards, etc very good devices. Even the Comfort Mouse 6000 was still great (though the die too fast, and have a hardware bug - middle click is delayed)

But nowadays it's all cheap plastic and cheap mechanics, made to last 2 years.

There are alternatives for good keyboards, but I have yet to find a good mouse. (a business mouse, not a rainbow colored funky gamer mouse)

Umm..

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

https://en.wikipedia.org/wiki/HP-UX

and HP is usually one of the best rather than worst here, though definitely more so in the pre-carly days.

though i get the general sentiment, esp when applied to consumer products..

Apple was not bad at both some time ago. Not anymore though.

iOS quality dropped jsut after the days of "everything must be skeuomorphic!" - that ux was thrown out quickly (luckily) but the replacement has been hardly stable and quite poorly thought from the inception, and some stuff is still giving me constant annoyance even today - like the time app not opening on the last used tab

It depends if you use the control center shortcut or not.

The good period was Apple hardware and NeXT software.

Apple?

iTunes

Apple?

Apple Music and iTunes? Both horrible.

Apple, I believe, is the wildly successful exception.

NVidia seems to produce excellent software (drivers, tools and SDK) for their excellent hardware.

SolarFlare network cards are also pretty good and so are their drivers and user space network stack.

In both cases the quality of the software side is a significant drive for their hardware sales.

In both cases the hardware is very expensive though.

NVidia seems to produce excellent software (drivers, tools and SDK) for their excellent hardware.

Here is a different perspective: https://googleprojectzero.blogspot.com/2017/02/attacking-win...

And "excellent hardware" is probably rather subjective as well.

Excellent software does not mean bug free of course. Apparently the size of the code base of the driver itself is comparable to that of a typical OS kernel.

Their hardware is pretty much best in class in both absolute performance and performance per watt, so I would say that it is a pretty objective evaluation.

> Their hardware is pretty much best in class in both absolute performance and performance per watt, so I would say that it is a pretty objective evaluation.

There are many more criteria:

- Openness: Open specification, existence of open source drivers, necessity for a firmware blob vs. open firmware, support of open standards

- Time the hardware is supported by producers with new drivers for new platforms (NVidia loves to cease support for older GPU chips).

- cost and cost-benefit ratio (the whole Intel vs. AMD vs. ARM flamewar ;-) )

- Existence of intentionally blocked features: Some hardware vendors intentionally block features, sometimes even with the possibility to unlock them afterwards (e.g. by firmware or fuses) if you pay them additional money

- Willingness to go to legal limbo in the interest of the users: For example when copy protection schemes for CDs were common in the early 00 years, producers of CD/DVD writers tried to surpass each other with capabilities of their devices to be still able to read out such copy-protected CDs. A modern example might be how other copy protection schemes for, say, audio or video are implemented: In software and written in such a bad way that it will (hopefully) soon be cracked or deeply dongled down in a security chip that is part of the hardware.

> (NVidia loves to cease support for older GPU chips).

As someone who deals with old GPU support daily, I challenge this! The most recent drivers still support Fermi chips (GT400 series) that were released over 7 years ago.

I'm not sure how long you expect a chip to be supported?

> As someone who deals with old GPU support daily, I challenge this! The most recent drivers still support Fermi chips (GT400 series) that were released over 7 years ago.

To deliver a source:

> http://www.tomshardware.com/news/nvidia-eol-graphics-card,26...

My opinion on how long a device should be supported: As long as there is no open specification available, one is dependent on the vendor to deliver updates. And graphics drivers are very prone to security bugs. So as long as devices still have a not tiny user base, the vendor has to provide security fixes for it. I would even love to say we should raise our standards and demand that a producer has to support their hardware up to the moment they release open specifications for it.

So you're talking about Tesla and earlier chips. Those are indeed only supported for the security fixes. The 34x.xx driver supports those chips, and they are indeed getting security updates.

I have personally fixed a couple of these issues[0], including for those "EOL'd" cards. The most recent posted drivers for these chips I'm seeing are 342.01 from 2016-12-14 for Windows and 340.102 from 2017-02-14 for Linux. That seems like it would check the "provide security fixes" box, no?

>has to support their hardware up to the moment they release open specifications for it.

I'd tend to agree, but as you can imagine this is quite a complex issue for us, so no comments here :)

[0]: http://www.nvidia.com/object/product-security.html

I have a pile of nvidia 5x0 cards that are now unusable under linux.

The rest of the hardware I bought that year still works fine (even stuff that's more obsolete than the nvidia cards).

AMD has usable (= works with modern Steam games, and suspend/resume) open source drivers, so I bet on them for the new video card. I guess we'll see how it worked out in 2022, or so.

Are you talking about the geforce 500 series[0]? They are still supported. Assuming the HW is still good, all drivers should still work. You can try with the NVIDIA driver included with the distribution (Ubuntu, Mint, etc), or download the one from nvidia.com

If it doesn't work, you can file a bug (see/use nvidia-bug-report.sh).

[0]: https://en.wikipedia.org/wiki/GeForce_500_series

They "work", just not with modern software. I found threads where the nvidia devs and the open source devs discussed the issue. Apparently, the nvidia drivers violate the opengl spec and drop textures at unpredictable times (such as during suspend and mode switches).

The "fix" is to constantly spam the same texture at the card, or use some some non-standard opengl extension to see when the driver decided to drop the textures, then recopy them from dram to the card (why keep one copy in video ram when you can keep a second in dram for twice the cost?)

From what I can tell, people are sick of implementing this workaround, so newer software doesn't bother. This has been the status quo for over a year.

In practice, this means severe screen corruption when switching users or suspending/resuming.

I've never seen that particular bug before, but the whole thing sounds totally plausible. Since it only manifests in Fermi, it's likely an arch issue. I'm guessing the workaround in the driver was deemed to messy/expensive compared to the one in the application.

I'll take a cursory glance at the issue, but if you've seen NV devs discuss it externally, it's probably well known internally, like closed as WNF.

I totally see where all sides are coming from, though:

* NV: Why spend resources fixing old architectures when it's easy to workaround at application level.

* Devs: Why spend resources supporting some obscure old HW that doesn't work right.

* Users: Why spend money replacing perfectly good HW, because NV/devs are lazy?

The more time passes, the less likely the first two are to do anything about it; and in time the number of users with those cards drops below epsilon. The easiest option is to just get HW that works with the SW you need - like you did.

I hope you are right, but there is not enough transparency to tell. From the discussion it sounded like modern hardware will behave the same, and maybe they'll try to amend the standard.

I didn't feel like betting $100's to find out if it hits on new hardware, but you can readily reproduce it on ElementaryOS with the 500's. You have to manually install the binary drivers with the ubuntu/debian proprietary driver tool, since ElementaryOS recommends the opensource ones.

This isn't the only distro that hit it, just the one I landed on in the end.

Anyway, for me the easiest option was to switch to open source drivers (where this kind of thing has a better track record of being fixed), and Nvidia is a non-starter there.

Nvidia are the people that require you to log in to get driver updates. Their "geforce experience" is mostly horrible, apart from Ansel and maybe the streaming thing.

I'm not a windows user, so I wouldn't know (the nvidia drivers from my os are an apt install away), but AFAIR the 'geforce experience' is not required to get the lastest version of the drivers, only for non essential tools.

That may explain your bias then.

Nvidia provides decent official Linux drivers, whereas manufacturers usually provide none.

On windows, all cards have decent drivers. Nvidia is not particularly remarkable.

Nvidia's software is bloated, requires login for features, telemetry without notifying the user and security issues in their drivers. I wouldn't really use them as a prime example.

With regards to your thoughts about the hardware being expensive, I found the following [1] article interesting. I'm mostly referring to the vendor lock-in part with CUDA.

[1]: https://streamcomputing.eu/blog/2014-08-05/7-things-nvidia-d...

Reply on news.ycombinator.com