My comments were based on experience. I'm a software developer that has worked on several commercial applications over the years, for a variety of markets. What is your commentary based on?
Every piece of software has a life-cycle, and version releases are just levels of maturity until the project is no longer worth the time and effort to put into it.
Whether or not you practice good release management has nothing to do with this fact. Those goals you speak of are for releases so that you can keep a lid on creeping featurism and not introduce new regressions. There is rarely, if ever, a penultimate and overarching engineering plan for any significant software project. Most developers aren't even totally sure what the project will do, or who will use it. It is the implementers that often drive most of the development changes over time. Take a look at this slide. Note the "maintenance" bullet. That is where the majority of your time and money is spent on a software project over the whole of it's life.
Software development lifecycles and management practices are well known. You might want to check here and here as well. Note that these are CompSci theories. In the Real World, software development rarely works out so cleanly.
In summary:
Software release management practices insist on version releases and sometimes redesign of fundamental aspects of the project. This is expected and useful.
All projects have a life-cycle, and reach the end of their useful life (in terms of maintenance). At this point they are grandfathered.
The second item does not indicate anyone "sucks". It's a fact of software development. Some projects have a longer life, some very short. It all depends on what it does, and who is using it.
...I've begun to recognize a pattern in software: when will we see the end?
Well, never.
Software design is unlike most every other discipline in the world. Your job is never finished until the product is dead. There are always bugs to fix, inconsistencies to remedy. Even the action of fixing bugs will create or uncover new ones. The fact is, if you release version 1.0, by definition you will also have to release version x.y for the entire life-cycle of the product. This also implies that versions may not be infinitely forwards- or backwards-compatible. At some point you have to abandon old releases.
Look at netBSD; it isn't dying, it's still working on its number-one goal: security.
According to the netBSD Goals page, security is not paramount. Certainly it take back seat to correctness of code, performance and wide platform support. Perhaps you mean OpenBSD? Either way, if you are going to make security your number one goal, you are compelled to updating and maintaining your code base! Security is a job that is never finished.
What if Linux all-of-a-sudden wanted to become a Micro Kernel? What if Microsoft(R) Windows(TM) all-of-a-sudden wanted to become a Micro Kernel?
Well, one of the early criticisms of Linux was that it wasn't a microkernel design. Some MINIX folks really thought Linus was taking a step backwards, though his intention was just to run a real UNIX on his intel box.
The NT kernel can be considered a microkernel. Very few "pure" microkernel implementations exist, and even fewer exist in the wild. By most definitions the Windows NT kernel is a microkernel.
Anyway, it's a moot point. Yes, redesigning the Linux kernel to be a microkernel would be significant, but this is why they have odd-number releases to shake the biggest bugs out. Architecture changes like this are part of any long-running project. Do I think they should do it? No. Do I think it would be more are less Linux? Again, no. If the only thing we could call linux is 2.4.x then the project is dead for sure.
How Microsoft or the PHP people label their respective products is really not that important. I'm not sure this is any kind of trick. Oh sure, Microsoft wants to make sure that people stay current, so it markets the latest release as The Best Ever, You'll See, but everyone does that. It helps their bottom-end in all sorts of ways, not just in immediate units sold.
Supporting old releases is expensive and painful. Few companies can afford to do so. How old releases are grandfathered is important, but we have to realize that old software must die. Personally, I'm glad Microsoft continued making improvements to Windows over the years (aren't you?). I just don't give a shit what they call it, as it is obviously cut from the same cloth when I fire up my desktop at work.
Does anyone think they should continue calling those products by their initial names AFTER the programming syntax and methodology becomes completly different or non-compatible than they were first designed?
I certainly do not agree.
The fact is that PHP 3, PHP 4 and PHP 5 all do the same sorts of jobs. The language will continue to run blogs and forums, process forms and maintain accounts for porn sites. That will not change. Eventually, as 5 matures it will replace 4 as the dominant release in current use. PHP is right for bumping the major version number when major architectural changed have been made. Whether or not syntax changes all that much (and from my review of the top article, the syntax of the language is not about to change radically) is relatively unimportant. As long as the provider (PHP) gives the implementer (the PHP developer) a heads-up on those changes, and sufficient time to revie
I, in fact, did read your posting. I disagreed with your contention that most people would not use it.
My examples were actually counter to any filetype association cruft that some operating systems default to. This is not what these types of file systems are about. Why limit yourself to three letters and a global registry entry that gives you one of a few static views?
*shrug* My only experience with RDBM-style filesystems is the BeFS. Folks who used BeOS didn't have to be technical wizards (most didn't even bother installing a POSIX shell). Everyone I know used the BeFS in this way, however, for aggregate data where it was useful. For example, most people just manipulated their MP3 files based on the information in the ID3 tags. They rarely viewed the filename ever again; with a few mouse clicks they made the Explorer view of their MP3 directories report bitrate, album name, etc. You could edit your ID3 tags through this views, as well. You could select a number of MP3's based on any number of keys and edit all the ID3 tags from the this same view. No third-party tool necessary. It just made sense, and was dead simple to do.
Once you opened a view on some other "directory", your view changes to the default one, or another view based on other, possible unique, meta-data.
Once you learn how do do this, it becomes a natural way to view the "filesystem".
Sure, only the power users defined their own meta-data to incorporate into specific views. Getting started was dead simply, however. The apps you used then could concentrate on doing what they did best, and cooperated with the OS to provide filesystem views.
I think it's important to note that this file system has a specific use: it's really geared toward user-interaction. This implies two things:
the user is interested in using it, and,
the primary concern of the filesystem is to return results back to a view in a manner appropriate for people to look at, and in a timely manner
This means that this is not the perfect filesystem for all reasons and all seasons. If all you need is a basic tree-structure, and have no need to hide or filter the generic view that Explorer gives you, then fine. If you are looking for a fileystem that can stream data at a tremendous rate, then another one may be more appropriate. Even a tree-structure may not be good anough, and you have to build an Oracle-like extents system on top of the raw device.
But if you are making a file system that returns searches in a timely manner, "feels" responsive through the clever use of threading, and allows for simple gestures that instantly change the way you present and manipulate file data, then something other than NTFS or ext2fs may be appropriate.
My only point was that Windows Explorer is arguably the most used application in the world. Making this application behave more appropriately based on existing or user-defined true file-type-specific meta-data is good. Being able to instantly contruct unique views based on these meta-data is a good. Certainly accepting near-human search strings based on keys that may be unique to us, and returning those results in a timely manner can only be a good thing.
Monolithic, system-wide and fixed "file attributes" just don't measure up. As long as Microsoft makes it as easy, or easier, to use as the BeFS, people will use it.
Ultimately, all I can say is "have you lived with such a filesystem before?" This is one of those things that you can just make more and more use of, as you gain experience. But you certainly don't need to be a power user to reasonably sort and search your MP3's or photos.
...many of these features are already available in one form or another and no one uses them
For most file data, perhaps.
I will use this, and to good effect, as well.
The point to take into consideration is that the context will also change depending on the metadata available. Your view of the aggregate file objects changes, depending on the context. Not to mention that this same metadata will be available, in the same format, to all participating applications. Your apps can have all the same view, if you like.
What this means in concrete terms is that your carefully sorted directory of MP3's can look like a file library in iTunes. There are searchable, sortable columns for Title, Album, bitrate, Cover Art, year, label, and whatever (note I did not say "filename", which is just another attribute under a modern filesystem). This is possible with only the most basic gestures on the part of the user, and is remembered for the next time you visit this same view.
Similarly, a tree of photographs appear in any participating file browser with whatever columns you want (bit depth, format, date taken, date published, ICC info). It's important to consider that you can do this with any arbitrary collection of data, even one's you define yourself (to take the BeFS example, anyway).
So you can take your collection of widgets, define attributes about these widgets, and your file browser applet works the same for the same user in all applications. It should, anyway. This is why we have APIs.
To cite your example, why visual grep through a bunch of thumbnails looking for a particular photo when you can just indicate with a few gestures the "type" of photo you are looking for? I like the iPhoto interface when I'm browsing photographs, but if I want a particular photo of the GF from a rough date taken at night, I certainly don't want to browse through 1000's of images, especially when some of them can be hard to discern at thumbnail resolutions. I certainly don't want to do this repeatedly when I'm assembling a photo album on a specific subject.
Let the computer do the grunt work of selecting a result set that matches my criteria, and then I can use my human abilities to select the object I want, or refine the search.
Most of us already keep our aggregate file types in associated groups on the filesystem already. In most cases, the tree structure of most filesystems is sufficient. All this does is extended the functionality of the filesystem so that you can choose to abstract aggregate file objects and treat them in a a myriad of different ways. In the most basic sense, you tell the OS, "look, when I have the Explorer/Finder open on this directory of MP3's, make sure you change the column view so it shows this, this and that. In icon view, make sure that mouse-over pop-ups (if enabled) display this that and that. Default sort is alphabetically by Artist's Last Name. I don't want to see the filename, as that doesn't contain any useful information."
That is, you don't have do anything special to make use of the file attributes in this way. You just tell the ultimate app that all of us use the most (the operating system's file browser) to treat certain directories in a different manner.
Well, I'll weigh in as an OS X pilot who surfs almost exclusively with Safari. Almost.
Like most people, I have to have a backup, in case something breaks. My habit has been to use Camino as a back-up browser. So far, this works ok for me. I'm a bit of a stickler for standards, so if a site doesn't work well I blame the site first, and not the browser; especially if I can compare/contrast between two browsers that are trying to behave in a standards-compliant way (even if the results are different).
But I digress. Regardless of the engine driving it, a browser is obviously a GUI-driven app, and I expect apps on Mac OS to behave and feel a certain way. The Mozilla/Firebird releases are not Mac OS native, at least in terms of look and feel, and I suspect that I (and many others) don't use them mainly for that reason.
Of course, this doesn't stop us from using the gecko-based Camino.
If I had need of the something that was more than a web browser, and wanted the whole suite of mail-news and web development that comes with a XUL-based app, I'd certainly be using Firebird. But I don't. I need a small, fast browser, and I have no complaints with Safari in this regard.
For those of us who want a browser to render a variety of sites in reasonably correct manner, most browsers will do. If you also want a look and feel consistent with the OS, with as little non-browser stuff as possible, Safari is an excellent choice.
Frankly, IE for Mac sucked on OS X. I have no knowledge of IE on OS 9. It lost it's edge by the time I started using a Mac, and the only reason I have it on my system drive is for one site that insists on using broken ECMA script that takes advantage of an IE trick (no, not a bank -- I bank just fine with Safari).
Tip: don't cook the macaroni in beer, but use the beer in the cheese and dairy mixture. Just heat it up in a saucepan (you can do this in the hot saucepan you just cooked the pasta in) and you have an excellent beer-cheese sauce. Reduce the amount of other liquid, of course, or your creation will be runny.
Stronger beers work better. Pretend pilseners like Bud will not be so good.
Remember: don't play with cheese sauce powder near an open flame. Unless you know what you are doing. And like setting things on fire. And second-degree burns. But only then.
Command-(n) is also nice, where (n) is a number from 1 to 9. Each Terminal window is assigned a unique (single-digit) number when spawned. Since my Terminals tend to be long-running, I can count on a session being Command-1 for a build, Command-2 for a man page or tests and Command-3 for something else.
File -> Set Title... and check "Command Key" gives you the visual cue for each window.
This also seems to be a common design for those Mac apps that have more than one "similar" document window.
I'm pretty sure that the same company that supplied the basic POSIX tools for Microsoft also provides POSIX tools for a great many other platforms, as well.
Microsoft cut a deal with this company to provide around 20 well-known POSIX tools (ls, tr, cat, tail,...) as part of the Windows server install. Customers can upgrade to the full supported package of POSIX tools and cross-platform bits and pieces for a fee.
Try strings ls.exe (or ident ls.exe if you have that magic available to you) and compare/contrast with the same executables on OS/390 or some big HP iron.
A variety of these tools have been available for the most common and obscure platforms for years.
[My apologies if this is a dupe. Our corporate internet activity was sporadic today, and my interrupted searches were coming up empty.]
My understanding of trademark law is that the onus is on the trademark holder to aggressively protect their registered marks against misuse and dilution.*
Perhaps this is all that is happening here. I'm sure TOG found some wording or statement by Apple that could be seen as trademark miuse, and were forced to protect their property.
I may not agree with all the uses of trademark law, but TOG may be forced to challenge many uses of "UNIX" just because they have to. That being said, Apple has been pretty reasonable in their use of phrases like "UNIX-based" and "BSD UNIX implementation"; I'm guessing there were enough minor "violations" according to trademark law that TOG needed to act.
* IANAL, but we had a trademark and patent laywer dude come around to our shop to give us a seminar a few weeks back. So now I'm a expert.
I was really talking about current Mac support from a desk-top, integration, usability point of view. Palm and Apple have, for the time being, formed a business relationship to promote each others' tech.
How long this lasts is always open to interpretation, but is out of our hands anyway. Currently, core funcitionality works Good Enough for me. That is, I can sync to everything I need (on Windows at work, on the Mac at home), and can drag and drop files to the palm via Bluetooth. This is the kind of support I'm talking about.
As for developer support, Palm seems happy enough to provide documents and links to free prc-tools and emulators for all platforms, including Mac. Took me only a few hours to set up a gcc cross-compiler and prc creation system on OS X. I'd never have considered Code Warrior as a dev platform, but according to Metrowerks, they still sell and support Code Warrior for the Mac. Perhaps if I coded for money for a variety of embedded targets and wanted a one-stop solution, I'd consider Code Warrior.
Anyway, my point still stands: if you want a handheld that has good Mac OS X support (where "support" is defined as above), you have to buy a new Palm.
The largest hole in this support is lack of third-party conduits, as these are generally very platform-specific, and tend to be targeted to the most common platform (i.e., Windows). The Mac Plam conduit API still exists and is supported by Palm.
As far as pilot-link is concerned, I didn't see much in the Docs section that gave anything more than what I already have with a default Palm-iSync-Mac setup.
Re:SCO still packs a punch?
on
SCO SCO SCO!
·
· Score: 1
I'm in for $100. As long as the code is release under a completely free license.
I did my research and at the time bought the Clie PEG-SL10 and I haven't looked back.
I also did some research -- for over a year -- and decided on a Palm Tungsten T over anything from Sony. I never considered a PocketPC.
Although Sony did have some very cool features, they all failed the "hand test". As soon as I actually held one in my hand, it felt sort of flimsy and toy-like. I'm left-handed, and it utterly failed the "hold it in the other hand" test. The Tungsten T passed this test for me, and with flying colours.
Over the last few weeks, it has passed all my usability tests, as well. This is where the Sharp Zaurus failed for me; it passed the hand test nicely, but as soon as I used it for any length of time, it's value decrease to almost 0, and off to eBay it went.
Of course, my decision was really made for me this time 'round: I use a Mac at home, and Palm is the only company that really supports Mac OS X.
My Tungsten T has bluetooth built in, for instance, but it can't be synched over Bluetooth.
Er?
I agree that iSync is really just a fat conduit that hooks up various bits to the Palm HotSync process, but I'm syncing My Tungsten T just fine over Bluetooth to my G4. The base station stays at work (on Win2000) and syncs up with Outlook (gotta use it -- corporate calendar/mail) for Calendar and ToDo lists only. Other stuff syncs to the Palm Desktop.
At home I sync up iCal and Address Book, everything else to Palm Desktop and no "backup" -- all over Bluetooth. I don't connect the Tungsten to a USB device at all at home.
It's all documented on the Palm and Apple support sites on how to do it.
The next trick for me will be connecting over Bluetooth to the Mac via pppd. I'm half the way there -- just need to sort of the connection chat details -- but the G4 is happily thinking the Bluetooth adpater is a 115k serial port and can see the start of a handshake from Palm on the other side of the "wire".
What the hell is a prog-rock super-band from the 80's doing with 22 million IP addresses?
Do they give them away to groupies with the backstage passes? Did entire blocks come free with the purchase of an lp? Were they traded for drugs and amps that go up to "11"?
In Canada you can copy a CD legally for "personal use"
Correct. The Copyright Act 1985 states flatly that you can make a copy (on any medium) of any musical recording for personal use. You do not even need to own the recording. In fact, it specifically legalizes personal recordings of someone else's copy of a musical work (according to the Copyright Board).
For example, it is illegal to grab a song from a P2P network and save it to my harddrive or a CD, as you cannot make a copy for yourself and a "friend".
However, simply ripping or making a verbatim copy of a CD for your own personal use is a right for all Canadian citizens.
Anyway, that's how I think with crimes, use flatfoot 101, "who profits?"
Perhaps this worm is a result of profiteering. However, many computer crimes do not follow this standard profile. "Traditional" (define that how you like) hacks n' cracks are most often done for motives other than profit (direct or indirect). I see no evidence to suggest this is changing.
While I think that the initial question posed in the OP has been addressed, I can't help but think that the real impact Pro Tools has had on commercial music is not lower overall production costs.
Like any software tool, Pro Tools can be an excellent way for skilled people to create good things. It can help novices or amateurs (see meaning [1]) develop their skills relatively cheaply. It can also create a whole universe of music that is flat, bland and mind-numbingly the same.
Whenever a particular tool becomes dominant in a field (whether it "deserves" to be dominant or not) it tends to place it's mark on a wide swath of work in that field. I'm thinking particularly of tools like Photoshop and Quark. Anyone who is familar with these tools is usually familar with the standard dreck that is churned out using them.
I've noticed the same trend with Pro Tools. In some ways, Pro Tools can be a bit of a lie: you can get four guys to stand up and belt out a tune and using Pro Tools you can normalize, compress, expand, quantize and otherwise tweak the hell out of the recording and make it sound good. Or at least as good as everything else.
There is a universal sameness to much Pro Tools produced music. Everything is limited to just below peak. Vocals are compressed, doubled and quantized to unearthly degrees. Each instrument is patched through the standard reverbs de rigueur. There are 128 tracks per song not because they are put to good use, but because you can have 128+ tracks per song.
This is not to say that Pro Tools can't be used to make good music. Nobody could say that, just as nobody could really say that Photoshop can't produce good print-ready images. But Photoshop is not a good tool to paint a picture, and Pro Tools does not replace the entire studio and a smart engineer with big ears behind the console.
As a musician, the trick is to know the limitations of your gadgets. Pro Tools will not, and can not, replace old-fashioned tracking, microphone placement, wet/dry mixes, or human-tuned compression.
The success of Pro Tools has created the Pro Tools sound, and one that I am not overly fond of. As music in the digital domain matures, I hope and expect we will move away from overuse of any single tool. This seems to be the history of popular music, anway.
Canadians have had the right to copy media for personal use for decades now. I don't know if this is related to the manufacturers tax levied on recordable digital media.
The ability to copy most any media (with some restrictions, natch) is a consumer right in Canada.
Exactly. Scale the hardware for the job. Sure, I'd love to use my unused 2-way PII box to replace my aging OBSD router, but I don't need all that grunt. Anyway, I could use it, but CPU1 would never be fired-up on boot.
Here at work we use modest boxes with OBSD running on them that acts as company-wide worldwide mailservers. When we needed more power to do some heavy lifting via spam filters, we just split the mailserver into two boxes (one for spam filtering, one for delivery).
SMP is a neat feature that has real advantages for a select few applications. Nobody I know uses OBSD for these applications.
Slashdot Mirror
My comments were based on experience. I'm a software developer that has worked on several commercial applications over the years, for a variety of markets. What is your commentary based on?
Every piece of software has a life-cycle, and version releases are just levels of maturity until the project is no longer worth the time and effort to put into it.
Whether or not you practice good release management has nothing to do with this fact. Those goals you speak of are for releases so that you can keep a lid on creeping featurism and not introduce new regressions. There is rarely, if ever, a penultimate and overarching engineering plan for any significant software project. Most developers aren't even totally sure what the project will do, or who will use it. It is the implementers that often drive most of the development changes over time. Take a look at this slide. Note the "maintenance" bullet. That is where the majority of your time and money is spent on a software project over the whole of it's life.
Software development lifecycles and management practices are well known. You might want to check here and here as well. Note that these are CompSci theories. In the Real World, software development rarely works out so cleanly.
In summary:
The second item does not indicate anyone "sucks". It's a fact of software development. Some projects have a longer life, some very short. It all depends on what it does, and who is using it.
Well, never.
Software design is unlike most every other discipline in the world. Your job is never finished until the product is dead. There are always bugs to fix, inconsistencies to remedy. Even the action of fixing bugs will create or uncover new ones. The fact is, if you release version 1.0, by definition you will also have to release version x.y for the entire life-cycle of the product. This also implies that versions may not be infinitely forwards- or backwards-compatible. At some point you have to abandon old releases.
According to the netBSD Goals page, security is not paramount. Certainly it take back seat to correctness of code, performance and wide platform support. Perhaps you mean OpenBSD? Either way, if you are going to make security your number one goal, you are compelled to updating and maintaining your code base! Security is a job that is never finished.
Well, one of the early criticisms of Linux was that it wasn't a microkernel design. Some MINIX folks really thought Linus was taking a step backwards, though his intention was just to run a real UNIX on his intel box.
The NT kernel can be considered a microkernel. Very few "pure" microkernel implementations exist, and even fewer exist in the wild. By most definitions the Windows NT kernel is a microkernel.
Anyway, it's a moot point. Yes, redesigning the Linux kernel to be a microkernel would be significant, but this is why they have odd-number releases to shake the biggest bugs out. Architecture changes like this are part of any long-running project. Do I think they should do it? No. Do I think it would be more are less Linux? Again, no. If the only thing we could call linux is 2.4.x then the project is dead for sure.
How Microsoft or the PHP people label their respective products is really not that important. I'm not sure this is any kind of trick. Oh sure, Microsoft wants to make sure that people stay current, so it markets the latest release as The Best Ever, You'll See, but everyone does that. It helps their bottom-end in all sorts of ways, not just in immediate units sold.
Supporting old releases is expensive and painful. Few companies can afford to do so. How old releases are grandfathered is important, but we have to realize that old software must die. Personally, I'm glad Microsoft continued making improvements to Windows over the years (aren't you?). I just don't give a shit what they call it, as it is obviously cut from the same cloth when I fire up my desktop at work.
I certainly do not agree.
The fact is that PHP 3, PHP 4 and PHP 5 all do the same sorts of jobs. The language will continue to run blogs and forums, process forms and maintain accounts for porn sites. That will not change. Eventually, as 5 matures it will replace 4 as the dominant release in current use. PHP is right for bumping the major version number when major architectural changed have been made. Whether or not syntax changes all that much (and from my review of the top article, the syntax of the language is not about to change radically) is relatively unimportant. As long as the provider (PHP) gives the implementer (the PHP developer) a heads-up on those changes, and sufficient time to revie
I, in fact, did read your posting. I disagreed with your contention that most people would not use it.
My examples were actually counter to any filetype association cruft that some operating systems default to. This is not what these types of file systems are about. Why limit yourself to three letters and a global registry entry that gives you one of a few static views?
*shrug* My only experience with RDBM-style filesystems is the BeFS. Folks who used BeOS didn't have to be technical wizards (most didn't even bother installing a POSIX shell). Everyone I know used the BeFS in this way, however, for aggregate data where it was useful. For example, most people just manipulated their MP3 files based on the information in the ID3 tags. They rarely viewed the filename ever again; with a few mouse clicks they made the Explorer view of their MP3 directories report bitrate, album name, etc. You could edit your ID3 tags through this views, as well. You could select a number of MP3's based on any number of keys and edit all the ID3 tags from the this same view. No third-party tool necessary. It just made sense, and was dead simple to do.
Once you opened a view on some other "directory", your view changes to the default one, or another view based on other, possible unique, meta-data.
Once you learn how do do this, it becomes a natural way to view the "filesystem".
Sure, only the power users defined their own meta-data to incorporate into specific views. Getting started was dead simply, however. The apps you used then could concentrate on doing what they did best, and cooperated with the OS to provide filesystem views.
I think it's important to note that this file system has a specific use: it's really geared toward user-interaction. This implies two things:
This means that this is not the perfect filesystem for all reasons and all seasons. If all you need is a basic tree-structure, and have no need to hide or filter the generic view that Explorer gives you, then fine. If you are looking for a fileystem that can stream data at a tremendous rate, then another one may be more appropriate. Even a tree-structure may not be good anough, and you have to build an Oracle-like extents system on top of the raw device.
But if you are making a file system that returns searches in a timely manner, "feels" responsive through the clever use of threading, and allows for simple gestures that instantly change the way you present and manipulate file data, then something other than NTFS or ext2fs may be appropriate.
My only point was that Windows Explorer is arguably the most used application in the world. Making this application behave more appropriately based on existing or user-defined true file-type-specific meta-data is good. Being able to instantly contruct unique views based on these meta-data is a good. Certainly accepting near-human search strings based on keys that may be unique to us, and returning those results in a timely manner can only be a good thing.
Monolithic, system-wide and fixed "file attributes" just don't measure up. As long as Microsoft makes it as easy, or easier, to use as the BeFS, people will use it.
Ultimately, all I can say is "have you lived with such a filesystem before?" This is one of those things that you can just make more and more use of, as you gain experience. But you certainly don't need to be a power user to reasonably sort and search your MP3's or photos.
For most file data, perhaps.
I will use this, and to good effect, as well.
The point to take into consideration is that the context will also change depending on the metadata available. Your view of the aggregate file objects changes, depending on the context. Not to mention that this same metadata will be available, in the same format, to all participating applications. Your apps can have all the same view, if you like.
What this means in concrete terms is that your carefully sorted directory of MP3's can look like a file library in iTunes. There are searchable, sortable columns for Title, Album, bitrate, Cover Art, year, label, and whatever (note I did not say "filename", which is just another attribute under a modern filesystem). This is possible with only the most basic gestures on the part of the user, and is remembered for the next time you visit this same view.
Similarly, a tree of photographs appear in any participating file browser with whatever columns you want (bit depth, format, date taken, date published, ICC info). It's important to consider that you can do this with any arbitrary collection of data, even one's you define yourself (to take the BeFS example, anyway).
So you can take your collection of widgets, define attributes about these widgets, and your file browser applet works the same for the same user in all applications. It should, anyway. This is why we have APIs.
To cite your example, why visual grep through a bunch of thumbnails looking for a particular photo when you can just indicate with a few gestures the "type" of photo you are looking for? I like the iPhoto interface when I'm browsing photographs, but if I want a particular photo of the GF from a rough date taken at night, I certainly don't want to browse through 1000's of images, especially when some of them can be hard to discern at thumbnail resolutions. I certainly don't want to do this repeatedly when I'm assembling a photo album on a specific subject.
Let the computer do the grunt work of selecting a result set that matches my criteria, and then I can use my human abilities to select the object I want, or refine the search.
Most of us already keep our aggregate file types in associated groups on the filesystem already. In most cases, the tree structure of most filesystems is sufficient. All this does is extended the functionality of the filesystem so that you can choose to abstract aggregate file objects and treat them in a a myriad of different ways. In the most basic sense, you tell the OS, "look, when I have the Explorer/Finder open on this directory of MP3's, make sure you change the column view so it shows this, this and that. In icon view, make sure that mouse-over pop-ups (if enabled) display this that and that. Default sort is alphabetically by Artist's Last Name. I don't want to see the filename, as that doesn't contain any useful information."
That is, you don't have do anything special to make use of the file attributes in this way. You just tell the ultimate app that all of us use the most (the operating system's file browser) to treat certain directories in a different manner.
It must be cool if they named-dropped Rob Malda and Slashdot!
the article references back to Slash:
Well, I'll weigh in as an OS X pilot who surfs almost exclusively with Safari. Almost.
Like most people, I have to have a backup, in case something breaks. My habit has been to use Camino as a back-up browser. So far, this works ok for me. I'm a bit of a stickler for standards, so if a site doesn't work well I blame the site first, and not the browser; especially if I can compare/contrast between two browsers that are trying to behave in a standards-compliant way (even if the results are different).
But I digress. Regardless of the engine driving it, a browser is obviously a GUI-driven app, and I expect apps on Mac OS to behave and feel a certain way. The Mozilla/Firebird releases are not Mac OS native, at least in terms of look and feel, and I suspect that I (and many others) don't use them mainly for that reason.
Of course, this doesn't stop us from using the gecko-based Camino.
If I had need of the something that was more than a web browser, and wanted the whole suite of mail-news and web development that comes with a XUL-based app, I'd certainly be using Firebird. But I don't. I need a small, fast browser, and I have no complaints with Safari in this regard.
For those of us who want a browser to render a variety of sites in reasonably correct manner, most browsers will do. If you also want a look and feel consistent with the OS, with as little non-browser stuff as possible, Safari is an excellent choice.
Frankly, IE for Mac sucked on OS X. I have no knowledge of IE on OS 9. It lost it's edge by the time I started using a Mac, and the only reason I have it on my system drive is for one site that insists on using broken ECMA script that takes advantage of an IE trick (no, not a bank -- I bank just fine with Safari).
Tip: don't cook the macaroni in beer, but use the beer in the cheese and dairy mixture. Just heat it up in a saucepan (you can do this in the hot saucepan you just cooked the pasta in) and you have an excellent beer-cheese sauce. Reduce the amount of other liquid, of course, or your creation will be runny.
Stronger beers work better. Pretend pilseners like Bud will not be so good.
Remember: don't play with cheese sauce powder near an open flame. Unless you know what you are doing. And like setting things on fire. And second-degree burns. But only then.
Command-(n) is also nice, where (n) is a number from 1 to 9. Each Terminal window is assigned a unique (single-digit) number when spawned. Since my Terminals tend to be long-running, I can count on a session being Command-1 for a build, Command-2 for a man page or tests and Command-3 for something else.
File -> Set Title... and check "Command Key" gives you the visual cue for each window.
This also seems to be a common design for those Mac apps that have more than one "similar" document window.
I'm pretty sure that the same company that supplied the basic POSIX tools for Microsoft also provides POSIX tools for a great many other platforms, as well.
Microsoft cut a deal with this company to provide around 20 well-known POSIX tools (ls, tr, cat, tail, ...) as part of the Windows server install. Customers can upgrade to the full supported package of POSIX tools and cross-platform bits and pieces for a fee.
Try strings ls.exe (or ident ls.exe if you have that magic available to you) and compare/contrast with the same executables on OS/390 or some big HP iron.
A variety of these tools have been available for the most common and obscure platforms for years.
[My apologies if this is a dupe. Our corporate internet activity was sporadic today, and my interrupted searches were coming up empty.]
My understanding of trademark law is that the onus is on the trademark holder to aggressively protect their registered marks against misuse and dilution.*
Perhaps this is all that is happening here. I'm sure TOG found some wording or statement by Apple that could be seen as trademark miuse, and were forced to protect their property.
I may not agree with all the uses of trademark law, but TOG may be forced to challenge many uses of "UNIX" just because they have to. That being said, Apple has been pretty reasonable in their use of phrases like "UNIX-based" and "BSD UNIX implementation"; I'm guessing there were enough minor "violations" according to trademark law that TOG needed to act.
* IANAL, but we had a trademark and patent laywer dude come around to our shop to give us a seminar a few weeks back. So now I'm a expert.
I was really talking about current Mac support from a desk-top, integration, usability point of view. Palm and Apple have, for the time being, formed a business relationship to promote each others' tech.
How long this lasts is always open to interpretation, but is out of our hands anyway. Currently, core funcitionality works Good Enough for me. That is, I can sync to everything I need (on Windows at work, on the Mac at home), and can drag and drop files to the palm via Bluetooth. This is the kind of support I'm talking about.
As for developer support, Palm seems happy enough to provide documents and links to free prc-tools and emulators for all platforms, including Mac. Took me only a few hours to set up a gcc cross-compiler and prc creation system on OS X. I'd never have considered Code Warrior as a dev platform, but according to Metrowerks, they still sell and support Code Warrior for the Mac. Perhaps if I coded for money for a variety of embedded targets and wanted a one-stop solution, I'd consider Code Warrior.
Anyway, my point still stands: if you want a handheld that has good Mac OS X support (where "support" is defined as above), you have to buy a new Palm.
The largest hole in this support is lack of third-party conduits, as these are generally very platform-specific, and tend to be targeted to the most common platform (i.e., Windows). The Mac Plam conduit API still exists and is supported by Palm.
As far as pilot-link is concerned, I didn't see much in the Docs section that gave anything more than what I already have with a default Palm-iSync-Mac setup.
I'm in for $100. As long as the code is release under a completely free license.
I also did some research -- for over a year -- and decided on a Palm Tungsten T over anything from Sony. I never considered a PocketPC.
Although Sony did have some very cool features, they all failed the "hand test". As soon as I actually held one in my hand, it felt sort of flimsy and toy-like. I'm left-handed, and it utterly failed the "hold it in the other hand" test. The Tungsten T passed this test for me, and with flying colours.
Over the last few weeks, it has passed all my usability tests, as well. This is where the Sharp Zaurus failed for me; it passed the hand test nicely, but as soon as I used it for any length of time, it's value decrease to almost 0, and off to eBay it went.
Of course, my decision was really made for me this time 'round: I use a Mac at home, and Palm is the only company that really supports Mac OS X.
I'll probably get a media reader instead, however.
Er?
I agree that iSync is really just a fat conduit that hooks up various bits to the Palm HotSync process, but I'm syncing My Tungsten T just fine over Bluetooth to my G4. The base station stays at work (on Win2000) and syncs up with Outlook (gotta use it -- corporate calendar/mail) for Calendar and ToDo lists only. Other stuff syncs to the Palm Desktop.
At home I sync up iCal and Address Book, everything else to Palm Desktop and no "backup" -- all over Bluetooth. I don't connect the Tungsten to a USB device at all at home.
It's all documented on the Palm and Apple support sites on how to do it.
The next trick for me will be connecting over Bluetooth to the Mac via pppd. I'm half the way there -- just need to sort of the connection chat details -- but the G4 is happily thinking the Bluetooth adpater is a 115k serial port and can see the start of a handshake from Palm on the other side of the "wire".
"iChat on crack" indeed.
My first unsolicited message from an unknown party (I apologize for the language):
Hrmph.
You've checked out Missing Sync, right?
Once they get past their early pop stage and start experimenting with epic songs in a minor key, they can rechristen themselves "The Scare Quotes".
What the hell is a prog-rock super-band from the 80's doing with 22 million IP addresses?
Do they give them away to groupies with the backstage passes? Did entire blocks come free with the purchase of an lp? Were they traded for drugs and amps that go up to "11"?
This kind of rock n' roll excess is just so sad.
Correct. The Copyright Act 1985 states flatly that you can make a copy (on any medium) of any musical recording for personal use. You do not even need to own the recording. In fact, it specifically legalizes personal recordings of someone else's copy of a musical work (according to the Copyright Board).
Here's the legal reference. Check out this interpretation of the current law.
For example, it is illegal to grab a song from a P2P network and save it to my harddrive or a CD, as you cannot make a copy for yourself and a "friend".
However, simply ripping or making a verbatim copy of a CD for your own personal use is a right for all Canadian citizens.
Perhaps this worm is a result of profiteering. However, many computer crimes do not follow this standard profile. "Traditional" (define that how you like) hacks n' cracks are most often done for motives other than profit (direct or indirect). I see no evidence to suggest this is changing.
I feel your pain.
Well, having a Mac can't be all good.
While I think that the initial question posed in the OP has been addressed, I can't help but think that the real impact Pro Tools has had on commercial music is not lower overall production costs.
Like any software tool, Pro Tools can be an excellent way for skilled people to create good things. It can help novices or amateurs (see meaning [1]) develop their skills relatively cheaply. It can also create a whole universe of music that is flat, bland and mind-numbingly the same.
Whenever a particular tool becomes dominant in a field (whether it "deserves" to be dominant or not) it tends to place it's mark on a wide swath of work in that field. I'm thinking particularly of tools like Photoshop and Quark. Anyone who is familar with these tools is usually familar with the standard dreck that is churned out using them.
I've noticed the same trend with Pro Tools. In some ways, Pro Tools can be a bit of a lie: you can get four guys to stand up and belt out a tune and using Pro Tools you can normalize, compress, expand, quantize and otherwise tweak the hell out of the recording and make it sound good. Or at least as good as everything else.
There is a universal sameness to much Pro Tools produced music. Everything is limited to just below peak. Vocals are compressed, doubled and quantized to unearthly degrees. Each instrument is patched through the standard reverbs de rigueur. There are 128 tracks per song not because they are put to good use, but because you can have 128+ tracks per song.
This is not to say that Pro Tools can't be used to make good music. Nobody could say that, just as nobody could really say that Photoshop can't produce good print-ready images. But Photoshop is not a good tool to paint a picture, and Pro Tools does not replace the entire studio and a smart engineer with big ears behind the console.
As a musician, the trick is to know the limitations of your gadgets. Pro Tools will not, and can not, replace old-fashioned tracking, microphone placement, wet/dry mixes, or human-tuned compression.
The success of Pro Tools has created the Pro Tools sound, and one that I am not overly fond of. As music in the digital domain matures, I hope and expect we will move away from overuse of any single tool. This seems to be the history of popular music, anway.
Canadians have had the right to copy media for personal use for decades now. I don't know if this is related to the manufacturers tax levied on recordable digital media.
The ability to copy most any media (with some restrictions, natch) is a consumer right in Canada.
Exactly. Scale the hardware for the job. Sure, I'd love to use my unused 2-way PII box to replace my aging OBSD router, but I don't need all that grunt. Anyway, I could use it, but CPU1 would never be fired-up on boot.
Here at work we use modest boxes with OBSD running on them that acts as company-wide worldwide mailservers. When we needed more power to do some heavy lifting via spam filters, we just split the mailserver into two boxes (one for spam filtering, one for delivery).
SMP is a neat feature that has real advantages for a select few applications. Nobody I know uses OBSD for these applications.