Earlier quoted context omitted.
>Apple doesn't actually make hardware I don't understand this comment. Apple absolutely makes their own hardware. They pride themselves on the A4/5 series processors and took meticulous care in designing the unibody styling that their laptops have.
They design the hardware, but they don't manufacture it.
Death to .DS_Store
51–60 of 127 posts
Re: Death to .DS_Store
#52Earlier quoted context omitted.
Since Linux has no such construct by default. Does that make it the most user-friendly?
KDE's Dolphin creates annoying .directory files.
Re: Death to .DS_Store
#53I have not encountered .DS_Store files enough for them to annoy me, but the same design flaw works itself into my life almost every day, in the form of zip files. When zipping files on OSX, the common way is to right click on your directory of choice in Finder and select “Archive as…”. This creates a Zip file, with the unwanted addition of a _macosx folder. According to this [1] article, the folder is used for thumbn…
That is what the "_macosx" folder contains, only these days the resource fork is only used to store cached data such as thumbnails, window positions, etc. But it didn't always use to be that way, and for compatibility's sake we're stuck :(
Re: Death to .DS_Store
#54I was clicking on that link for hours before I realised, what a way to spend christmas.
Re: Death to .DS_Store
#55Earlier quoted context omitted.
Unix users are offended by all the useless carriage returns in HTTP too, (and heaven forbid source files) but there just has to be some tolerance if we are all to get along. You can probably augment your VFS dispatch functions to never report a .DS_Store file and to delete one and retry any time a directory remove fails and you'll never know they exist! Or you could just ignore them the way Unix users ignore carriage…
Funny, I'm on a Linux system more often than Mac or Windows and the carriage returns drive me insane. Also, because the Windows users on my team are the ones that can't manage to figure out how to get their IDE or Git to leave our line endings alone. Our least performing team member dominates our git stats because he repeatedly manages to change nearly every line of code in our project.
Re: Death to .DS_Store
#56Why did they change they article to a link to the google cache? Google has since re-cached the page, and the cache now links to itself. I was clicking on that link for hours before I realised, what a way to spend christmas.
http://viewtext.org/article?url=http%3A%2F%2Fwww.aorensoftwa...
Re: Death to .DS_Store
#57defaults write com.apple.desktopservices DSDontWriteNetworkStores true
Re: Death to .DS_Store
#58Why did they change they article to a link to the google cache? Google has since re-cached the page, and the cache now links to itself. I was clicking on that link for hours before I realised, what a way to spend christmas.
Re: Death to .DS_Store
#59I have not encountered .DS_Store files enough for them to annoy me, but the same design flaw works itself into my life almost every day, in the form of zip files. When zipping files on OSX, the common way is to right click on your directory of choice in Finder and select “Archive as…”. This creates a Zip file, with the unwanted addition of a _macosx folder. According to this [1] article, the folder is used for thumbn…
In Mac OS X you can (or could at one time) attach extra meaningful data to a file, classically known as the "Resource Fork". In the pre-OS X days applications were often bundled by placing images, audio, etc. in the application file's resource fork. I remember in the 90's finding an application that had a huge (for its day) multi-megabyte resource fork, but only a few kilobytes of program data in the data fork. That…
Re: Death to .DS_Store
#60Earlier quoted context omitted.
Windows has always had more configuration than OSX. OSX - supposed to be simple to use and the defaults are supposed to "just work" and make sense to most people (drag an "icon" to the "trash" to "uninstall" it made no sense to me) Linux (old-school) - made for users who care about the details and will take days or weeks to set up their system. Arch is still like this. Stuff adheres to philosophical standards and POS…
You must be thinking of the Linux fantasists registry, not the real one, as the real registry has Windows ACLs and users can only write to HKCU by default, admin rights are needed to write to HKLM or HKCR. And "one of the worst ideas of all time" provided a system-wide centralised, standardised configuration database accessible from vbscript and command line, as well as app code, with user specific settings migratabl…
You are a little wrong there about Linux. Nearly all configuration files are in one of two places, /etc or dot folders in the root of my home folder. I can't write to the files in /etc as a user, and the config files in my home folder only apply to me. (Incidentally, since most Windows users at home run as administrator, they have access to the system configurations).
Personally, I don't like the registry because it is a binary blob (and having .ini files spread everywhere is much worse). I like human editable configuration files spread out in a folder hierarchy. I can use the same tools to modify configurations as everything else, as (nearly) everything is a file. I modify configurations with a text editor, I copy the configurations as files etc. It also allows me to get a better understanding of the configurations, since I can easily have comments and can literally copy and paste between text editors to migrate partial configurations.
In terms of a networking environment, applying configurations from a central user server is probably easier with windows due to the nature of the registry. However, due to the separation of system and user configuration on Linux, this is not an issue. You have /etc configuration as part of a 'system image', and can update this using tools like puppet. Then you have your user configuration migrate with a users network filesystem.