Hacker News Reader

> So? Millions of users do want it, judging from the huge popularity of Dropbox

Yet just about everyone uses local FS with cloud for backup or sharing of a small subset. Giving us an odd cloud first strategy seems more suited for a phone or severely storage constrained devices.

> Again, irrelevant. Lots of Mac users, and tons of pundits HAVE asked for a "new proprietary filesystem" to replace HFS+

Seem to remember that most of that conversation was of ZFS. They even got a long way into the ZFS port before abandoning. HFS+ has been getting long in the tooth for years, so a better FS is long overdue! So now we're getting APFS that explicitly doesn't checksum user data[0]! With current storage size, that's disappointing to understate it hugely.

> until Intel delivers boards that accept 32GB low-power RAM

It's funny, if Apple had not significantly reduced the Wh of MBP batteries in the latest generation we could easily have had both. Probably a longer overall life. Teardowns show a lot of empty space around current batteries.

[0] http://dtrace.org/blogs/ahl/2016/06/19/apfs-part5/#apfs-data

>Giving us an odd cloud first strategy seems more suited for a phone or severely storage constrained devices.

What "odd cloud first strategy"? Cloud is just ANOTHER option, not a "first" or privileged one. To the point that Apple also includes a whole new local filesystem (in beta) with Sierra.

>Seem to remember that most of that conversation was of ZFS. They even got a long way into the ZFS port before abandoning.

Oracle bought Sun and poisoned the area with patents and threats.

>It's funny, if Apple had not significantly reduced the Wh of MBP batteries in the latest generation we could easily have had both.

No, we really couldn't. At best we'd have a 10% or so larger battery space. The impact of RAM (there whether you use 32GB or fewer for a task or not) is much larger.

To comment on Apple's "cloud first" strategy, while they do provide local file storage in their APIs, their guideline suggests avoiding creating an option for storing local files since users "expect all of their files to be available on all of their devices." (https://developer.apple.com/ios/human-interface-guidelines/i...)

> Yet just about everyone uses local FS with cloud for backup or sharing of a small subset.

In most cases, not because they want to, but because that's how current software works. Both Dropbox and Google Drive focus on having their own special folder that gets synced; syncing the OS desktop and documents folders is possible but only with special configuration (on both Windows and macOS).

Cloud first makes perfect sense no matter how much or how little storage you have. It prevents you from losing data if your device is lost or damaged, and if you have multiple devices it allows accessing all your data from any device. If anything, its usefulness depends more on internet connection speed.

I do think Apple's specific cloud storage offerings could be improved for large devices. Currently the highest tier of iCloud storage is 2TB, which costs $20/mo; that's only twice as large as my MacBook Pro's SSD, and fairly expensive. But it's the same price/GB as both Google Drive and Dropbox, so it can't be that much of a ripoff...

> You can still format the rest of the hard disk on another fs to dual boot, and you can still share drives with other systems in NTFS, xFAT, etc.

Until that other OS has support for the new proprietary filesystem, it won't be able to read it. Since Apple and Microsoft categorically refuse to implement any of the many featureful existing filesystems, one is stuck with archaic NTFS (with no file permissions) or FAT (with less than 4gb files) to keep data.

>Since Apple and Microsoft categorically refuse to implement any of the many featureful existing filesystems, one is stuck with archaic NTFS (with no file permissions) or FAT (with less than 4gb files) to keep data.

xFAT which I already mentioned is supported and doesn't have a 4GB limitation. You can have up to 128 pebibytes (which should be enough for everybody: that's ~144 petabytes).

> which should be enough for everybody

I've heard these words so often that they've lost any meaning to me. :)

Why do you think there’s no file permissions in NTFS?

In NTFS, each file or directory can have arbitrary access control list specifying granted and denied permissions for users and groups.

Those lists are typically inherited down the directory hierarchy, but that inheritance can be stopped.

Glad you agree the keyboard sucks

> First, there's nothing "toy: about Swift. It's a full featured language on par with Rust, Go, etc.

A language with no promises of stability counts as a "toy" in my mind (I understand that this can be subjective, just providing my opinion).

Say what you want about Objective-C, but at least Apple stuck with basic syntax decisions.

That kind of oversimplifies things. From my reading of the Swift mailing list, many things you would consider "basic syntax decisions" will have a profound impact on the stabilisation of the ABI.

Migrating is a pain, but I'll take the Swift migration pain over the maintenance of old Objective-C code any day. Even on large projects.

As a Linux/Windows developer, Swift remains a toy language as it cannot be used to do develop useful applications for Linux and Windows, where I make all of my money.

As a Linux/Windows developer, you probably are not the primary target audience of Swift.

As a developer for Apple platforms, am I right to consider C# or Java toy languages, too?

There are thousands of Apple and Android C# apps (see Xamarin).

Which, again, is besides the point. The parent was mocking the idea that just because a language doesn't support a platform it can be called a "toy language".

C# that he mentioned wouldn't be toy languages even if there were 0 Apple and Android C# apps. It would just be a totally professional Windows language with no Android/iOS support.

C# was professional even when it only supported Windows (and partially FreeBSD), before Mono came along...

> C# was professional even when it only supported Windows (and partially FreeBSD), before Mono came along...

As well as the decade-plus when Mono existed but wasn't owned by Microsoft, making cross-platform support merely incidental or even a negative from Microsoft's perspective.

There are many Java apps for Mac and Apple used to provide its own implementation of the JRE.

>As a Linux/Windows developer

As a Linux/Windows developer you are not the target audience (which I already addressed).

Besides, just because you can't use it, it doesn't make it a toy language, just a language that doesn't have support (or full support) for Linux.

A toy language has a specific meaning, it's not a generic work for "language I can't use professionally on my platform/industry".

I can't use Forth to make web apps either, which is were I make all of my money, but it's not a toy language by any means.

Yes, it's wrong to be dismissive like that. But no, "toy language" does not have a specific meaning. It is a slang insult, not a proper technical term.

Seems like a bit much to say that it's a toy language because it can't (currently) be used to write Linux or Windows applications. There's probably tens of thousands of developers at least making a living developing Swift applications. I bet there's more people making money writing Swift than Haskell and Lisp combined.

First, there's nothing "toy: about Swift. It's a full featured language on par with Rust, Go, etc.

That's some amazing CoolAid you've got there. But I'll grant you that it's on the same level with a bunch of other new languages that also aren't in general use for serious long term products yet.

But until Intel delivers boards that accept 32GB low-power RAM of the kind that goes into Apple laptops, we're not gonna get it.

Yeah, wouldn't it be great if Apple made this happen? That's the kind of innovation I want to see.

As for the bulk of the rest of your points, developers and common Mac users have different priorities, and your opinions are not mine. Who better represents professional developers will take time to find out.

You want Apple to make their own CPUs?

No, I want Apple to do what they've done in the past and get Intel to do something for them. http://mrob.com/pub/comp/mac-models.html#intel_special

>Yeah, wouldn't it be great if Apple made this happen? That's the kind of innovation I want to see.

Adding something with marginal utility for the majority of their users (since even pros can do just fine with 16GB) just because some insignificant minority runs multiple VMs on their Macs?

That's not the kind of innovation Apple was ever, ever, interested in.