Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Did we lose our way in making efficient software?

rufatmammadli.medium.com

Post reply on HN
Print view View original

491–500 of 515 posts

Re: Did we lose our way in making efficient software?

#491

Post by bouke »

michelb wrote: post #90

In my MacOS Passwords I have ±3400 entries. A roughly 341KB CSV. Searching in that list in the preference panel or Keychain app is dog-slow on my M1 Pro Studio or on my M3 MacBook Air. How??

When the first MacBooks came out with a Secure Enclave, Keychain was just unworkable slow. You had to type your search query elsewhere and then paste it in, or you’d be looking at a beachball for minutes. Took them a major OS X release before it became somewhat bearable again.

The new Passwords is a joke. UX errors all over the place, modal based view with a toggle to start editing. If you need to enter a password in another area of System Preferences, you need to back out of the auth flow, switch to Passwords and copy the credentials over to a temporary file.

Re: Did we lose our way in making efficient software?

#492

Post by fch42 »

mike_hearn wrote: post #413
fch42 wrote: post #271

Earlier quoted context omitted.

To quote Wolfgang Pauli, this is not just not right, it's not even wrong ... The "C ABI" and libc are a rather stable part of Linux. Changing the behaviour of system calls ? Linus himself will be after you. And libc interfaces, to the largest part, "are" UNIX - it's what IEEE1003.1 defines. While Linux' glibc extends that, it doesn't break it. That's not the least what symbol revisions are for, and glibc is a huge us…

Things do break sadly, all the time, because the GNU symbol versioning scheme is badly designed, badly documented and has extremely poor usability. I've been doing this stuff for over 20 years now [1] [2], and over that time period have had to help people resolve mysterious errors caused by this stuff over and over and over again. Good platforms allow you to build on newer versions whilst targeting older versions. De…

Thanks for extensive examples of "the mess"...

I'd only like to add one thing here ... on static linking.

It's not a panacea. For non-local applications (network services), it may isolate you from compatibility issues, but only to a degree.

First, there are Linux syscalls with "version featuritis" - and by design. Meaning kernel 4.x may support a different feature set for the given syscall than 5.x or 6.x. Nothing wrong with feature flags at all ... but a complication nonetheless. Dynamic linking against libc may take advantage of newer features of the host platform whereas the statically linked binary may need recompilation.

Second, certain "features" of UNIX are not implemented by the kernel. The biggest one there is "everything names" - whether hostnames/DNS, users/groups, named services ... all that infra has "defined" UNIX interfaces (get...ent, get...name..., ...) yet the implementation is entirely userland. It's libc which ties this together - it makes sure that every app on a given host / in a given container gets the same name/ID mappings. This does not matter for networked applications which do not "have" (or "use") any host-local IDs, and whether the DNS lookup for that app and the rest of the system gives the same result is irrelevant if all-there-is is pid1 of the respective docker container / k8s pod. But it would affect applications that share host state. Heck, the kernel's NFS code _calls out to a userland helper_ for ID mapping because of this. Reimplement it from scratch ... and there is absolutely no way for your app and the system's view to be "identical". glibc's nss code is ... a true abyss.

Another such example is (another "historical" wart) timezones or localization. glibc abstracts this for you, but language runtime reimplementations exist (like the C++2x date libs) that may or may not use the same underlying state - and may or may not behave the same when statically compiled and the binary run on a different host.

Static linking "solves" compatibility issues also only to a degree.

Re: Did we lose our way in making efficient software?

#493

Post by nottorp »

nottorp wrote: post #107
nwah1 wrote: post #27

Office 365 probably would have worked. Microsoft's proprietary format is handled best by Microsoft. Also, cloud-based synchronization using CRDTs is a complex problem that is significantly more complex than just loading the document. Can't claim we are going backwards when comparing apples and oranges.

That's clutching at straws tbh. I have a "native" google docs spreadsheet that has atm 4 sheets, all at 50 lines or less. No fancy formulas except sums. It just tracks hours for billing. It uses 500 Mb of ram fresh, and in a couple weeks it goes up to 1.5 to 2 Gb and I have to kill the tab and reopen it. This is the modern javascript world...

Hey I just killed a github tab that was at 1.2 Gb :)

Re: Did we lose our way in making efficient software?

#494

Post by mattl »

internetter wrote: post #84
mattl wrote: post #44

Earlier quoted context omitted.

Only if you want to distribute via the App Store. There’s also TestFlight and distribution of source code I believe if you want to avoid that.

Both of these are completely false. Testflight distribution without a developer license is impossible. Asking users to compile the app themself is infeasible, as the XCode toolchain is upwards of 18gb and they will be required to compile it once every week to keep it on their device. The developer fee is unavoidable — even with EU intervention

My own poor wording.. I'm talking about avoiding the App Store not avoiding the license.

Re: Did we lose our way in making efficient software?

#495

Post by Animats »

NoGravitas wrote: post #457
Animats wrote: post #285

Earlier quoted context omitted.

.bashrc hasn't change since 2021. But Ubuntu pushed a new /usr/bin/bash in mid-March.

It's more likely to be system-provided config files like bash-completions.

It's Ubuntu, with their automatic updates. Canonical is now at least as intrusive as Microsoft was in the days of Windows 7.

Re: Did we lose our way in making efficient software?

#496

Post by mattpallissard »

mike_hearn wrote: post #413
fch42 wrote: post #271

Earlier quoted context omitted.

To quote Wolfgang Pauli, this is not just not right, it's not even wrong ... The "C ABI" and libc are a rather stable part of Linux. Changing the behaviour of system calls ? Linus himself will be after you. And libc interfaces, to the largest part, "are" UNIX - it's what IEEE1003.1 defines. While Linux' glibc extends that, it doesn't break it. That's not the least what symbol revisions are for, and glibc is a huge us…

Things do break sadly, all the time, because the GNU symbol versioning scheme is badly designed, badly documented and has extremely poor usability. I've been doing this stuff for over 20 years now [1] [2], and over that time period have had to help people resolve mysterious errors caused by this stuff over and over and over again. Good platforms allow you to build on newer versions whilst targeting older versions. De…

> How to do this is documented only in the middle of a dusty ld manual nobody has ever read.

This got an audible laugh out of me.

> Good platforms allow you to build on newer versions whilst targeting older versions.

I haven't been doing this for 20 years (13), but I've written a fair amount of C. This, among other things, is what made me start dabbling with zig.

  ~  gcc -o foo foo.c
  ~  du -sh foo
  16K foo
  ~  readelf -sW foo | grep 'GLIBC' | sort -h
       1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.34 (2)
       3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND puts@GLIBC_2.2.5 (3)
       6: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.34
       6: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND __cxa_finalize@GLIBC_2.2.5 (3)
       9: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND puts@GLIBC_2.2.5
      22: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND __cxa_finalize@GLIBC_2.2.5
  ~  ldd foo                                 
    linux-vdso.so.1 (0x00007ffc1cbac000)
    libc.so.6 => /usr/lib/libc.so.6 (0x00007f9c3a849000)
    /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f9c3aa72000)


  ~  zig cc -target x86_64-linux-gnu.2.5 foo.c -o foo
  ~  du -sh foo
  8.0K  foo
  ~  readelf -sW foo | grep 'GLIBC' | sort -h        
       1: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.2.5 (2)
       3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND printf@GLIBC_2.2.5 (2)
  ~  ldd foo                                 
    linux-vdso.so.1 (0x00007ffde2a76000)
    libc.so.6 => /usr/lib/libc.so.6 (0x0000718e94965000)
    /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x0000718e94b89000)
edit: I haven't built anything complicated with zig as I have with the other c build systems, but so far it seems to have some legit quality of life improvements.

Re: Did we lose our way in making efficient software?

#497

Post by dTal »

GnarfGnarf wrote: post #490
dTal wrote: post #484

Earlier quoted context omitted.

Funny, I've never once in all my days installed malware from a Linux package manager, and this "seal of approval" doesn't cost me or the developer any money at all.

That’s because your computer is a hobby, and mine is a business. My customers use Windows and macOS. They have happily paid for my house, my car and my retirement. :o)

If you want to justify rent-seeking because it helps you pay for your lifestyle, come out and say so in the first place instead of pretending it's for the benefit of your users. But claiming that Linux is a "hobby" on HN is essentially trolling.

Re: Did we lose our way in making efficient software?

#498

Post by wredue »

wsc981 wrote: post #312
wredue wrote: post #301

Earlier quoted context omitted.

You don’t have to do any of that for native apps either. What on earth is happening in this comment section?

I think on macOS it's kinda a requirement, even if you ship outside of the AppStore, to be trusted by consumers. Because I think the app needs to be signed by Apple, in order to start the app without a warning and I think in order for Apple to perform the signing, you'd need a developer account. I might be wrong here as I have been focused pretty much only on mobile, so feel free to correct me.

It’s a warning once that stops happening when you approve it. It’s not a big deal. Also happens on windows.

Re: Did we lose our way in making efficient software?

#499

Post by mike_hearn »

mattpallissard wrote: post #496
mike_hearn wrote: post #413

Earlier quoted context omitted.

Things do break sadly, all the time, because the GNU symbol versioning scheme is badly designed, badly documented and has extremely poor usability. I've been doing this stuff for over 20 years now [1] [2], and over that time period have had to help people resolve mysterious errors caused by this stuff over and over and over again. Good platforms allow you to build on newer versions whilst targeting older versions. De…

> How to do this is documented only in the middle of a dusty ld manual nobody has ever read. This got an audible laugh out of me. > Good platforms allow you to build on newer versions whilst targeting older versions. I haven't been doing this for 20 years (13), but I've written a fair amount of C. This, among other things, is what made me start dabbling with zig. ~ gcc -o foo foo.c ~ du -sh foo 16K foo ~ readelf -sW…

Interesting that zig does this. I wonder what the binaries miss out on by defaulting to such an old symbol version. That's part of the problem of course: finding that out requires reverse engineering the glibc source code.

Re: Did we lose our way in making efficient software?

#500

Post by fch42 »

mike_hearn wrote: post #499
mattpallissard wrote: post #496

Earlier quoted context omitted.

> How to do this is documented only in the middle of a dusty ld manual nobody has ever read. This got an audible laugh out of me. > Good platforms allow you to build on newer versions whilst targeting older versions. I haven't been doing this for 20 years (13), but I've written a fair amount of C. This, among other things, is what made me start dabbling with zig. ~ gcc -o foo foo.c ~ du -sh foo 16K foo ~ readelf -sW…

Interesting that zig does this. I wonder what the binaries miss out on by defaulting to such an old symbol version. That's part of the problem of course: finding that out requires reverse engineering the glibc source code.

Maybe just nitpicking but he _specified_ the target version for the zig compile.

(Haven't tested what it would link against where that not given)

Post reply on HN