Live data from Hacker News

We need to document macOS

eclecticlight.co

81–90 of 266 posts

Re: We need to document macOS

#81

Earlier quoted context omitted.

Listen man, I do plenty of customization. What I'm bitching about here is what I consider to be a lack of innovation and a dereliction on obvious existing, key tools. Finder is a beautiful example of Apple not taking care of it's shit. I don't need a fucking hand hold. My 3 year old Macbook Air is in my opinion the BEST laptop available. I'm angry that the innovation appears to have ceased from the availible provider…

Your delusion that paying "availible [sic] providers" the large price tag they put on their electronics and 'doing plenty of customization' make them "your" tools is the reason I don't take you seriously; "your vernacular" is more an indicator than an issue in that regard. > The second they shape up, someone else delivers me an answer, or I write something to get me out of this platform, there I go. The first two are…

So, what point are you trying to make here? That everybody should write their own tools?

That seems like a pretty inefficient use of everybody's time.

Re: We need to document macOS

#82

When I did some work on porting out product to macOS (so developers could run their server environment locally, though a few loons wanted to actually run macOS on servers), I was immediately struck by how awful and incomplete the documentation was. And, I've been working in the Linux world for a couple decades...where docs are copious but wrong about 50% of the time. In particular, the service launcher (launchd, ment…

>And, I've been working in the Linux world for a couple

>decades...where docs are copious but wrong about 50% of the

>time.

Nice summary of the status of Linux documentation. Not sure if it's really 50% wrong, especially the man pages make an impression of over-corrected but the usefulness depends on the tool and is completely random. But yeah, online documentation, classical tutorials are usually useless. When I see a tutorial, I close the tab. They just lead to dirty installations. If a tool needs a documentation, there might be an alternative that needs none. ;) But seriously, a lot of stuff on Github is obvious to use.

Not sure about the macOS. Having changed from Linux to macOS as my main (laptop) OS, I first noticed the unusual BSD tools. So I installed GNU tools on my first year OS X. Now I just use the BSD tools, some I even prefer over the GNU versions. But I guess the stuff that has been developed by Apple has no docs at all..

Re: We need to document macOS

#83
post #39

Earlier quoted context omitted.

> "but a really terrible choice on the desktop" This is a very subjective claim. Maybe a long long time ago you could say this, but not the case today. > "not convinced that free software documentation is any better" That's beside the point. If that were true, that is an argument for focusing a community effort at improving documentation for a free desktop. And actually with linux the problem is not as much a lack of…

I shouldn't have to go to terminal to edit a conf file to make audio or video work. I have every single time I have tried Linux on the desktop. It does not work out of the box. You must know how to use terminal and edit Byzantine configurations, and read Linux forum posts from 2005 to make basic functionality work. It's my "subjective" opinion, but after 5+ hours troubleshooting and configuring as a power user who do…

> I shouldn't have to go to terminal to edit a conf file to make audio or video work.

I never needed to.

> It does not work out of the box.

It does.

> You must know how to use terminal and edit Byzantine configurations, and read Linux forum posts from 2005 to make basic functionality work.

What was your problem?

> It's my "subjective" opinion, but after 5+ hours troubleshooting and configuring as a power user who does know how to edit conf files I wouldn't recommend it to anyone.

You're lying, if you'd be a "power-user" then you wouldn't complain about manual text-based configuration.

Re: We need to document macOS

#84
post #49

Earlier quoted context omitted.

A beefy windows workstation or laptop to cover Adobe & DAWs + VMWare for Linux. With fullscreen VMWare and open-vm-tools I can barely notice that it doesn't run bare metal, and i can keep different distros at hand for different purposes.

I bought Windows 10 Pro last year and had really high hopes for it after the Ubuntu shim was introduced. Windows is a fucking nightmare for anything involving producing audio at a pro level. The Ubuntu shim does not solve what I need even though it's a nice add. The real kicker is that STILL many errors produce a window where I can't even fucking copy the output. Why that is still a feature, I have no idea. That coup…

> The real kicker is that STILL many errors produce a window where I can't even fucking copy the output. Why that is still a feature, I have no idea.

BTW a standard way to do it is to just press Ctrl+C in such window without any text selection or context menu. Because such messages could be shown when system has no resources to create context menu or text selection, and that was very important in 16-bit days.

Re: We need to document macOS

#86

When I did some work on porting out product to macOS (so developers could run their server environment locally, though a few loons wanted to actually run macOS on servers), I was immediately struck by how awful and incomplete the documentation was. And, I've been working in the Linux world for a couple decades...where docs are copious but wrong about 50% of the time. In particular, the service launcher (launchd, ment…

> But, I'm kinda baffled why anyone would volunteer to provide free labor to one of the largest and most profitable companies in the world. I give away tons of my time for OSS, but I'm not about to get out and push if I've paid for a luxury car. > I'd rather put my time into something that is free and open for everyone, including my future self. Actually, the word "rather" isn't strong enough: I would never give my l…

It's not Apple's work to do. It's not in their interest to document everything. What applies to internal APIs applies to lesser extent to the detailed workings of the OS, like the init system, themeing, etc.. If it is documented, people will depend on it, or write low-level tweaking tools that Apple doesn't want to exist.

What is good for customers and developers might not be good for Apple, and vice versa.

(A separate issue are the user docs, e.g. how to use Finder. I guess they are good enough, I haven't found the need for such docs.)

Re: We need to document macOS

#88

Earlier quoted context omitted.

I bought Windows 10 Pro last year and had really high hopes for it after the Ubuntu shim was introduced. Windows is a fucking nightmare for anything involving producing audio at a pro level. The Ubuntu shim does not solve what I need even though it's a nice add. The real kicker is that STILL many errors produce a window where I can't even fucking copy the output. Why that is still a feature, I have no idea. That coup…

> The real kicker is that STILL many errors produce a window where I can't even fucking copy the output. Why that is still a feature, I have no idea. BTW a standard way to do it is to just press Ctrl+C in such window without any text selection or context menu. Because such messages could be shown when system has no resources to create context menu or text selection, and that was very important in 16-bit days.

I'm sure your right. The fact that they haven't updated that and I've been in *nix/OSX for 8 years now made my frustration point maybe lower than it should have been. Then the next thing I'm doing is trying to use cmd and powershell and my hair falls out.

But this is great info and will definitely keep be from cursing quite as much next time I'm MS admining.

Re: We need to document macOS

#89

Earlier quoted context omitted.

I bought Windows 10 Pro last year and had really high hopes for it after the Ubuntu shim was introduced. Windows is a fucking nightmare for anything involving producing audio at a pro level. The Ubuntu shim does not solve what I need even though it's a nice add. The real kicker is that STILL many errors produce a window where I can't even fucking copy the output. Why that is still a feature, I have no idea. That coup…

> The real kicker is that STILL many errors produce a window where I can't even fucking copy the output. Why that is still a feature, I have no idea. BTW a standard way to do it is to just press Ctrl+C in such window without any text selection or context menu. Because such messages could be shown when system has no resources to create context menu or text selection, and that was very important in 16-bit days.

Let me klingon to the thread with this:

It's 2017 and I still can't use the keyboard to copy and paste from and to a Windows command line window...

Re: We need to document macOS

#90
post #89

Earlier quoted context omitted.

> The real kicker is that STILL many errors produce a window where I can't even fucking copy the output. Why that is still a feature, I have no idea. BTW a standard way to do it is to just press Ctrl+C in such window without any text selection or context menu. Because such messages could be shown when system has no resources to create context menu or text selection, and that was very important in 16-bit days.

Let me klingon to the thread with this: It's 2017 and I still can't use the keyboard to copy and paste from and to a Windows command line window...

Ctrl C and Ctrl V works in Windows 10 command prompt.
Post reply on HN