Ask HN: What are the less-mentioned drawbacks of acclaimed software / libraries?
2 comments
Maybe Qt is better than GTK. Does anybody claim Qt is better than the native widgets on any platform that has native widgets?
With Rust you can write safe and fast programs but you will spend a lot of time and mental energy fighting with the compiler. Go ahead and write C/C++ but remember that your life insurance doesn't pay out if you get killed playing Russian Roulette. For many cases people are happy with managed languages such as Java, C#, Python, etc.
F# is a similar story. It has benefits, but they really aren't enough to displace other languages.
MacOS? I like APFS. On MacOS they always reserve enough space for the text on a button in the UI. Send in a ticket for a problem like that to RHAT and you will get verbal abuse before they close it. (e.g. the 'Linux Desktop' is a Potempkin village) Windows sometimes gets confused when you have a large number of monitors with different dpi plugged in but it is nothing a reboot won't fix.)
Inside the dirty secret is that there is not a big difference in how modern OS really work. They all divide interrupt handlers into a top and a bottom, they all support POSIX system calls or something that is a POSIX rip-of (e.g. look at the MS-DOS syscalls) "Microkernels" are usually huge and wracked with optimizations, in real-life Unix has become "Plan 9 in Userspace".
A really superior OS would have to remove bloat, maybe the die-area eating space heaters such as the MMU and TLB. It would probably have a different viewpoint about synchronous vs asynchronous. If it was different enough to be "superior" than old code wouldn't run, you'd have to write the whole userspace -- so you'll stick to a POSIX API.
IBM knew how to make a universal instruction set architecture in 1965, but had no vision of a general-purpose mainframe OS until academic researchers invented "VM" which let them run three or five different OS on the machine so they didn't have to pick just one.
By 1995 the POSIX API is established and it is about as universal as the 360 instruction set. It is used in my car stereo, home theater receiver, TV set, tablet, internet router, PC, server, etc.
Even the "real time" or "reliable" OS used in a spacecraft or automotive application is likely to present itself as POSIX.
MacOS uses mach to emulate POSIX and mach lets you do a bit more than POSIX, but Linux has been subdividing the 'process' concept for a long time as has Windows NT. FUSE descends into microkernel insansity ("Plan999999999999999999999 from userspace")
With Rust you can write safe and fast programs but you will spend a lot of time and mental energy fighting with the compiler. Go ahead and write C/C++ but remember that your life insurance doesn't pay out if you get killed playing Russian Roulette. For many cases people are happy with managed languages such as Java, C#, Python, etc.
F# is a similar story. It has benefits, but they really aren't enough to displace other languages.
MacOS? I like APFS. On MacOS they always reserve enough space for the text on a button in the UI. Send in a ticket for a problem like that to RHAT and you will get verbal abuse before they close it. (e.g. the 'Linux Desktop' is a Potempkin village) Windows sometimes gets confused when you have a large number of monitors with different dpi plugged in but it is nothing a reboot won't fix.)
Inside the dirty secret is that there is not a big difference in how modern OS really work. They all divide interrupt handlers into a top and a bottom, they all support POSIX system calls or something that is a POSIX rip-of (e.g. look at the MS-DOS syscalls) "Microkernels" are usually huge and wracked with optimizations, in real-life Unix has become "Plan 9 in Userspace".
A really superior OS would have to remove bloat, maybe the die-area eating space heaters such as the MMU and TLB. It would probably have a different viewpoint about synchronous vs asynchronous. If it was different enough to be "superior" than old code wouldn't run, you'd have to write the whole userspace -- so you'll stick to a POSIX API.
IBM knew how to make a universal instruction set architecture in 1965, but had no vision of a general-purpose mainframe OS until academic researchers invented "VM" which let them run three or five different OS on the machine so they didn't have to pick just one.
By 1995 the POSIX API is established and it is about as universal as the 360 instruction set. It is used in my car stereo, home theater receiver, TV set, tablet, internet router, PC, server, etc.
Even the "real time" or "reliable" OS used in a spacecraft or automotive application is likely to present itself as POSIX.
MacOS uses mach to emulate POSIX and mach lets you do a bit more than POSIX, but Linux has been subdividing the 'process' concept for a long time as has Windows NT. FUSE descends into microkernel insansity ("Plan999999999999999999999 from userspace")
Anyone who says something has "technical superiority" is living in a fantasy world. Everything has pros and cons, and it's impossible to account for every variable upfront. You may be 99.999% done with a project only to realize that another language/framework/OS/etc. would have been better.
And there are many more in the list.
Now, apart from non technical things (eg: license complications of Qt), what are the drawbacks of such 'acclaimed' software programs or libraries that people should know?