5 ms·

Isn’t that a problem that Linux only has crappy cross platform apps that are not as good as native apps? Why would I run a Linux box as my daily driver instead

Isn’t that a problem that Linux only has crappy cross platform apps that are not as good as native apps? Why would I run a Linux box as my daily driver instead of a my Mac that is real Unix, has a 16 hour battery life and I can get great polished native apps?

klodolph 4y ago
I mean, it depends on how much time you're spending in great, polished native apps. For work, I spend all of my time in VS Code, Chrome, Slack, and the terminal. It's hard to justify any platform as being better if those are the apps you use, since they basically work the same on any platform. And then there are the people who spend day in, day out in programs like Photoshop, InDesign, Pro Tools, etc.
- PaulDavisThe1st 4y ago
  At least two of the final three you mentioned run on Windows and macOS, meaning that somewhere there's a cross-platform layer for the GUI. And yet apparently, that works. There's a lesson there, though I'm not sure what it is.
  - scarface74 4y ago
    Adobe and Microsoft both have spent 30 years optimizing their development around supporting both Macs and Windows. But how much of the GUI is actually cross platform? Adobe famously used Apple’s Carbon API and was very upset that it wasn’t ported to 64 bit. There is a lot of Cocoa in both products. Microsoft use to brag that they had more Mac developers than Apple did.
    - PaulDavisThe1st 4y ago
      > But how much of the GUI is actually cross platform I find the idea that when Photoshop or Protools wants to open a dialog with a button, the developer creates two functions, one for Windows and one for macOS, completely unbelievable. There is almost without doubt some level of in-house cross-platform toolkit in place. It may not go as far as, say, Qt tries to, and it may differ in design philosophy from other similar toolkits, but they are not writing twice the code every time they have do something in the GUI. If I'm wrong, HN is the place to find out.
      - scarface74 4y ago
        That’s kind of backwards isn’t it? If I am writing a banking app for both the web and mobile. My GUI development is going to be different. But I’m calling the same set of APIs. The backend isn’t “opening a dialog box” to the front end. The developers would be designing a native dialog and calling backend shared codex
        PaulDavisThe1st 4y ago
        I never said anything about the backend. The GUI code wants to open a dialog. The way to do that differs dramatically depending on whether you're opening a dialog on one of the (many) Windows native GUI APIs, or Cocoa (or even Linux). Are you proposing that when the, ahem, domain logic in Photoshop requires opening a dialog, that the developers write 2 or 3 or 4 different implementations at the call site? I would bet that they do not. Adobe has wrapped "dialog creation" (along with hundreds of other GUI abstractions) in their own cross-platform layer, and their GUI code calls that. This is the same thing done by pretty much any company developing for more than one platform. The approaches can differ a lot. For example, consider Reaper (another DAW). Its lead developer picked a tiny subset of the win32 API that he wanted to be able to use, and implemented that for macOS and Linux/X Window. Then he uses the (partial) win32 API for the entire GUI (with higher level stuff built on top of it).
        scarface74 4y ago
        > Are you proposing that when the, ahem, domain logic in Photoshop requires opening a dialog, that the developers write 2 or 3 or 4 different implementations at the call site? This is still backwards. The domain logic doesn’t open a dialog anymore than a back end API opens a dialog on a web app or mobile app. The front end gathers whatever information it needs to call the backend code along with an event saying when it’s done “call this”. The back end logic is usually naive to the presentation layer. Even in GUI apps it’s usually event based where the backend just sends an event saying “I’m done” and the front end registers an asynchronous function for a call back and when the function is called a dialog box shows up saying “done”.
  - klodolph 4y ago
    The lesson is that you can get great cross-platform UX if you have a massive budget. There’s some cross-platform UI code, sure, there’s also duplicated work. Photoshop was originally written using MacApp, so it must have gone through some extensive, extensive changes to get its first Windows version.
- scarface74 4y ago
  True. But even then the reason I prefer my Mac is that it integrates with my personal hardware. I do log in to my personal account on my work Mac But I am careful about what gets synced.
lelanthran 4y ago
> Why would I run a Linux box as my daily driver instead of a my Mac that is real Unix, has a 16 hour battery life and I can get great polished native apps? Depends on the apps you are using; what's the Mac equivalent of Emacs? How about Meld? Yeah, this is a bit of a leading question; you can get great polished native non-xplatform apps for Macs but if you limit yourself to that category then the Mac is no longer as useful as a mid-range Windows/Linux laptop. If you're going to insist on using only non-xplatform native apps when on Mac, you're in a niche (image/video/sound editing, maybe?) BTW: What kind of Mac laptop do you have that you get 16 hours of battery life? My 5mo M1 barely gets 4 hours when using only video-calling, Goland, Chrome and some terminals. In over a year of using a Mac as a daily driver, I've yet to use one non-xplatform native Mac application. so I am curious about what you non-xplatform native Mac app you are using.
- kitsunesoba 4y ago
  > BTW: What kind of Mac laptop do you have that you get 16 hours of battery life? My 5mo M1 barely gets 4 hours when using only video-calling, Goland, Chrome and some terminals. Hard to say without knowing what’s running in the terminals, but I’d say Chrome/Electron (and potentially, its use of non-HW-accelerated codecs in video chat) is the likely culprit here. Not the same machine, but my M1 Pro MBP 16” can pretty easily swing a full work day flipping between Xcode and Android Studio so long as I’m using Safari for browsing.
- scarface74 4y ago
  I have a (work issued) MacBook Pro 16 inch M2 Pro Mac. I charged it to 100% and it lasted two full work days on battery at a client site open most of the time running VS Code and Teams (some people were still remote) and occasionally building AWS Lambdas. The build tools let you build Lambdas within an Amazon Linux Docker container containing the appropriate runtimes when you are building on Windows or Macs.
deleted 4y ago
[deleted]
executesorder66 4y ago
> Why would I run a Linux box as my daily driver instead of a my Mac that is real Unix Because your real Unix ships with certifiably ancient GNU tools that haven't been updated since they switched to GPLv3 licences, and are a massive security risk. It doesn't even have a real package manager, which leads to things like this : https://news.ycombinator.com/item?id=35581375 https://news.ycombinator.com/item?id=35581375
- scarface74 4y ago
  Yes, because it’s impossible to download new versions are packages on the Mac…

klodolph 4y ago

I mean, it depends on how much time you're spending in great, polished native apps. For work, I spend all of my time in VS Code, Chrome, Slack, and the terminal. It's hard to justify any platform as being better if those are the apps you use, since they basically work the same on any platform. And then there are the people who spend day in, day out in programs like Photoshop, InDesign, Pro Tools, etc.

PaulDavisThe1st 4y ago
At least two of the final three you mentioned run on Windows and macOS, meaning that somewhere there's a cross-platform layer for the GUI. And yet apparently, that works. There's a lesson there, though I'm not sure what it is.
- scarface74 4y ago
  Adobe and Microsoft both have spent 30 years optimizing their development around supporting both Macs and Windows. But how much of the GUI is actually cross platform? Adobe famously used Apple’s Carbon API and was very upset that it wasn’t ported to 64 bit. There is a lot of Cocoa in both products. Microsoft use to brag that they had more Mac developers than Apple did.
  - PaulDavisThe1st 4y ago
    > But how much of the GUI is actually cross platform I find the idea that when Photoshop or Protools wants to open a dialog with a button, the developer creates two functions, one for Windows and one for macOS, completely unbelievable. There is almost without doubt some level of in-house cross-platform toolkit in place. It may not go as far as, say, Qt tries to, and it may differ in design philosophy from other similar toolkits, but they are not writing twice the code every time they have do something in the GUI. If I'm wrong, HN is the place to find out.
    - scarface74 4y ago
      That’s kind of backwards isn’t it? If I am writing a banking app for both the web and mobile. My GUI development is going to be different. But I’m calling the same set of APIs. The backend isn’t “opening a dialog box” to the front end. The developers would be designing a native dialog and calling backend shared codex
      - PaulDavisThe1st 4y ago
        I never said anything about the backend. The GUI code wants to open a dialog. The way to do that differs dramatically depending on whether you're opening a dialog on one of the (many) Windows native GUI APIs, or Cocoa (or even Linux). Are you proposing that when the, ahem, domain logic in Photoshop requires opening a dialog, that the developers write 2 or 3 or 4 different implementations at the call site? I would bet that they do not. Adobe has wrapped "dialog creation" (along with hundreds of other GUI abstractions) in their own cross-platform layer, and their GUI code calls that. This is the same thing done by pretty much any company developing for more than one platform. The approaches can differ a lot. For example, consider Reaper (another DAW). Its lead developer picked a tiny subset of the win32 API that he wanted to be able to use, and implemented that for macOS and Linux/X Window. Then he uses the (partial) win32 API for the entire GUI (with higher level stuff built on top of it).
        scarface74 4y ago
        > Are you proposing that when the, ahem, domain logic in Photoshop requires opening a dialog, that the developers write 2 or 3 or 4 different implementations at the call site? This is still backwards. The domain logic doesn’t open a dialog anymore than a back end API opens a dialog on a web app or mobile app. The front end gathers whatever information it needs to call the backend code along with an event saying when it’s done “call this”. The back end logic is usually naive to the presentation layer. Even in GUI apps it’s usually event based where the backend just sends an event saying “I’m done” and the front end registers an asynchronous function for a call back and when the function is called a dialog box shows up saying “done”.
- klodolph 4y ago
  The lesson is that you can get great cross-platform UX if you have a massive budget. There’s some cross-platform UI code, sure, there’s also duplicated work. Photoshop was originally written using MacApp, so it must have gone through some extensive, extensive changes to get its first Windows version.
scarface74 4y ago
True. But even then the reason I prefer my Mac is that it integrates with my personal hardware. I do log in to my personal account on my work Mac But I am careful about what gets synced.

lelanthran 4y ago

> Why would I run a Linux box as my daily driver instead of a my Mac that is real Unix, has a 16 hour battery life and I can get great polished native apps? Depends on the apps you are using; what's the Mac equivalent of Emacs? How about Meld? Yeah, this is a bit of a leading question; you can get great polished native non-xplatform apps for Macs but if you limit yourself to that category then the Mac is no longer as useful as a mid-range Windows/Linux laptop. If you're going to insist on using only non-xplatform native apps when on Mac, you're in a niche (image/video/sound editing, maybe?) BTW: What kind of Mac laptop do you have that you get 16 hours of battery life? My 5mo M1 barely gets 4 hours when using only video-calling, Goland, Chrome and some terminals. In over a year of using a Mac as a daily driver, I've yet to use one non-xplatform native Mac application. so I am curious about what you non-xplatform native Mac app you are using.

kitsunesoba 4y ago
> BTW: What kind of Mac laptop do you have that you get 16 hours of battery life? My 5mo M1 barely gets 4 hours when using only video-calling, Goland, Chrome and some terminals. Hard to say without knowing what’s running in the terminals, but I’d say Chrome/Electron (and potentially, its use of non-HW-accelerated codecs in video chat) is the likely culprit here. Not the same machine, but my M1 Pro MBP 16” can pretty easily swing a full work day flipping between Xcode and Android Studio so long as I’m using Safari for browsing.
scarface74 4y ago
I have a (work issued) MacBook Pro 16 inch M2 Pro Mac. I charged it to 100% and it lasted two full work days on battery at a client site open most of the time running VS Code and Teams (some people were still remote) and occasionally building AWS Lambdas. The build tools let you build Lambdas within an Amazon Linux Docker container containing the appropriate runtimes when you are building on Windows or Macs.

deleted 4y ago

[deleted]

executesorder66 4y ago

> Why would I run a Linux box as my daily driver instead of a my Mac that is real Unix Because your real Unix ships with certifiably ancient GNU tools that haven't been updated since they switched to GPLv3 licences, and are a massive security risk. It doesn't even have a real package manager, which leads to things like this : https://news.ycombinator.com/item?id=35581375 https://news.ycombinator.com/item?id=35581375

scarface74 4y ago
Yes, because it’s impossible to download new versions are packages on the Mac…