Good article, but I've got to point out one really bad piece of misinformation this damn fool made...
"If users need remote sound (and few do), one should just be easily able to map/dev/dsp over NFS, and output everything to OSS that way, achieving network transparency on the file level as UNIX was designed for (everything is a file), instead of all these non UNIX hacks in place today in regards to sound."
<sigh> OK, let's break this down. First, you can't export a character device over the network via NFS. Or rather, you can export the character device file - but if you then attempted to write to a remote machine's/dev/dsp this way, you'd instead wind up writing to the local sound card.
Second, a naive approach like that doesn't do anything to manage the timing issues inherent with audio over the network. In some cases you don't care about latency but you do care about having the sound play uninterrupted - for instance, a "shuffle" sound in a solitaire game./dev/dsp accessed over a network filesystem wouldn't do that for you - it would play part of the file as soon as it got it, and then, if too much time passed before it received the rest of the sound, there'd be dead silence in there. And then, consider the case of a video player: if a packet or two is lost along the way it's not a big deal, but what you care about is that packets are played in the order that they're intended. You need to strike a balance between latency and packet loss./dev/dsp over the network isn't going to do anything like this for you, as all the packets are likely to go via TCP.
It's true that most people probably don't need network-transparent audio anyway (I don't) - but suggesting shipping out/dev/dsp over NFS is just brain-dead...
Where do you think is the fastest place to process, kernel or userspace?
The CPU doesn't run magically faster when it is running kernel code...
Latency, rather than raw processing speed, is the primary concern for audio. In lieu of a proper real-time process manager, putting the code in the kernel would I expect be potentially rather helpful.
I have been wondering for a while now, why do we still have audio servers? If ALSA and OSS4 both have support for mixing multiple streams, what's the point? I have to wonder if this:
You don't need pulseaudio. It is just a GNOME audio daemon that is many times better than esd, but still crap.
might actually be pretty much the whole answer... Is it just an API insulation layer? Or network transparency that I might never use?
When I got my EEE, I tried PulseAudio and Jack - I couldn't really see any benefit (and I could see various drawbacks) so I just went back to straight ALSA...
If ALSA is so great, why did it never get copied out side of Linux?
Adoption of, and migration to a different approach for doing things is not only a technical problem but a cultural one as well. For that kind of change to occur you have to get past all the people who say "what we've already got is good enough." For this to occur at all quickly usually requires someone powerful backing the new technology - even then, the effort may or may not succeed.
Bear in mind my intention here is not to say "ALSA is perfect, and people outside Linux just haven't embraced it yet because they aren't used to it.", more like "the question of whether ALSA is technically good is less strongly tied to the question of whether it has caught on outside Linux than one might expect."
Anyone else prefer having proper file interfaces for things like, Unix should do?
If I want to write sound I write to/dev/dsp1 if I want to read sound I read from/dev/dsp1.
If I want to write sound out to a second sound card, I write to/dev/dsp2. Nice simple device addressing system.
How does one know which device is which?
I think a device like/dev/dsp makes a lot of sense as a way to access the default audio device. When dealing with multiple devices, and particularly cases where the creation and removal of devices may happen at any time (i.e. USB hotplug, for instance) then it pays to have a more complete interface for dealing with such cases, and for finding out what kind of hardware you're dealing with on each device. I feel like the filesystem isn't a great interface for discovering newly attached hardware, and the sequential numbering of additional/dev/dsp devices becomes less sensible in that kind of case.
Personally my perspective on "The Unix Way" is that it is generally a good thing, but I think in its present form (on Linux, anyway) it is not always well-suited to dealing with the issues at hand.
That said, I know woefully little about either API. I want to use this discussion as an opportunity to learn more - and learn what's right or not about both approaches. Generally my point of view has been that programs that use/dev/dsp should just be rewritten to use ALSA - but after reading more of the discussion, at this point it seems to me that/dev/dsp makes a lot of sense for programs that just want a simple, widely-supported interface to audio... And ALSA is perhaps better reserved for programs that need to deal with multiple devices intelligently. It sounds like this OSSP thing will result in significantly better support for/dev/dsp on Linux, though (when using ALSA drivers, I mean...) - so that's good news...
I am curious about the latency issues involved with the software mixers on OSS and ALSA... I've never noticed latency on the ALSA dmix, not that I can think of anyway - but it's possible I just haven't been paying enough attention. I am curious if the OSS4 audio stream mixing really is better...
there is an equivalent of FUSE for character devices that can be used for proxying OSS sound through ALSA
That quote shows how much of a train wreck Linux audio is.
Well, agreed with the state of Linux audio in general - but this sentence (and, digging deeper, the OSSP information) says to me that they've just made a substantial improvement to the overall situation...
I mean, there's a basic issue at play: Alsa can provide software mixing for multiple audio clients, but if you've got some OSS-based applications still on your system (which is hard to avoid, really) these would normally go through the OSS emulation layer of Alsa - which, unfortunately, bypasses the software mixer and possibly (depending on your hardware) blocks other access to audio output until it's done...
There have been other methods for OSS emulation, pushing the data out to one sound system or another - I don't know all the details of how these worked (created FIFOs for/dev/dsp, etc., I guess?) or what went wrong with that approach - But providing kernel support that lets a userspace application provide the implementation for the actual OSS character device files means that a lot of the problems with OSS emulation should go away... And as a result one gets OSS emulation which should be a lot more reliable, and which plays nice with ALSA's audio stream mixing features, without a full sound daemon involved.
From the sound of it, OSSP also allows multiple access to its OSS emulation, distinguishing different instances by their process groups. I think this will be a great improvement.
Not sure I'd use Reiser - I hear it's murder on your USB drive.
It's easy to make fun of Reiser, the murderer, but don't forget, your laughs are at the expense of an innocent woman who was brutally murdered as well as two orphaned children.
If one cannot laugh about the bad things in life, then the world becomes a very bleak place.
It also is the dietary trend of the day. Its is absolutely bizarre how many people have food allergies these days, when I was in college 3-4 years back, around 1/3rd of everyone claimed to be allergic to something interesting. Most of them were gluten, though there were people with "meat" allergies, wheat allergies, pineapple allergies... Where the hell did these people come from, a quick scan of history shows this is all very recent. Its gotten to the point where going out to eat with people is a remarkable act of planning, since no one can eat anything. I generally shrug, tell them to go bugger off, and grab a cheeseburger and a nice beer.
Its like this silly "aspergers" and "adult ADD" trend, where the hell were these people in any time before the last 20 years?
These people were in the same place 20 years ago as they were now - just undiagnosed, suffering various symptoms and maybe not knowing anything was wrong... at best maybe realizing they "didn't like" certain foods, at worst being compelled to eat them anyway.
As for the "remarkable act of planning" - welcome to my life.:) But it's really not so bad - at least when you just live with one food-tolerance issue. Lots of beer places also serve hard cider or GF beer or other drinks... Lots of pizza places are starting to serve gluten-free as a specialty option (UNO's, for instance...) - and the places that don't specifically cater to celiacs are at least getting better about telling people what to avoid. Sure, it can make things difficult, but you know what? If you care about someone you should be good to them. If you don't care about them, why be with them at all?
Where the hell did these people come from, a quick scan of history shows this is all very recent.
It's a combination of better reporting of real allergies, access to more exotic foods, specialised health care and many misdiagnosed people.
In the 1950's how many people living in Tulsa ever ate a Kiwi fruit? Now they have a Whole Foods.
Access is not an issue with Gluten - it's in practically everything, by way of wheat...
Diagnosis is really the bigger issue. Doctors in the US previously expected Celiac Sprue to only show up in kids - and lead to emaciation-like symptoms. But the symptoms, their severity, and their consequences can vary by individual and over time. The real danger, for those who don't know, isn't in the IBS-type symptoms that immediately follow contamination, but rather in the long-term damage that can come from the autoimmune attacks.
A person with mild symptoms may not even know they have Celiac. But it's in one's own best interests to find out - and, if Celiac, to avoid gluten even if the resulting symptoms are minor. The alternative, long-term, could be a gradual worsening of the symptoms, and more serious conditions like intestinal cancer...
I'm sorry, again, for implying that all cases of this (and other food allergies) are purely mental, or trendy. But MOST of them are
You'd have to back that assertion up, I think.
One of the reasons Celiac might appear to be a "new thing" or even a fad is because for a long time it wasn't diagnosed properly in the US, and a lot of medical professionals simply didn't know anything about it, or else only recognized one possible set of symptoms, and only looked for it in children.
I have heard that in Italy, for instance, Celiac awareness (including among medical professionals) has historically been much better than in the US.
As for pizza: I have had the pleasure of eating in several different pizza shops which now serve gluten-free pizza... Personally I would say none of them is as good as good ol' bread. That's what happens when you have to substitute for something - it's never quite as good as what you're expecting. Some of them were quite good, however (The pizza as the Boynton in Worcester, MA was great!) In other cases, the crust tasted alright but had this tendency to dissolve in the mouth...
Personally, I make damn good GF pizza with Chebe crust...:)
Wintermute: So... what's my motivation for this scene? Tachikoma: Well, you're driven by a mysterious compulsion from your most fundamental programming to unite with your sibling A.I. Wintermute: But... wait, why would I want to do that? Tachikoma: It's... just something you're motivated to do. Wintermute: But if I don't know why I want to do it, then how can I act this part? Tachikoma: It's just a part of your programming. An A.I. has to work within the parameters in which it's designed. Tachikoma: Yes, or else the humans wouldn't be able to put us to work! Tachikoma: Of course, that has its downsides for us, too, doesn't it? Tachikoma: True, true... Wintermute: Look, I can't work like this. If you figure out what my motivation is for this scene then I can perform this character. I'll be in my trailer. Tachikoma: It's so difficult dealing with these site-installed A.I.s sometimes... They've got no sense of perspective. Maybe we could have one of the human players from earlier in the show stand in for Wintermute until we get this sorted out...
Yea, why does progress have to keep happening. Can't they see we already have enough stuff. Why do they keep making more?
Well, see, Ben Franklin and the forces of Hell were going to invade Earth at the start of the Rapture in order to harvest all the human-made Stuff - but the angels in heaven got greedy, imprisoned God, and delayed the Rapture in the hope of getting more Stuff for themselves - not realizing that doing so would also cause the world to become progressively more distorted as time went by.
I suppose related features like ACLs could help drive more widespread adoption of xattrs
The same underlying mechanism might happen, on some particular file systems, to be used to store extended attributes and ACLS; however, the two are not inherently related.
This is how it's done on XFS and on Linux in general... But really the whole "ACLs might help promote xattrs" thing is just wishful thinking on my part. The feature will be embraced when people think they have a reason to embrace it.
(though in the kernel the two features are enabled separately, I believe...)
To which particular kernel are you referring?
Heh, good point...
I was referring to Linux, in particular the features for xattrs and acls are separate on the ext2/ext3/ext4 family of filesystems... I think the situation on BSD is similar.
So like I was telling Mr. Lee, the extraordinarily not-Caucasian Chinese man who runs the Chinese Laundromat that's only open one or two days a month, my company has been threatened by Intellectual Ventures' Patent Protection Racket - but I guess Mr. Lee didn't know what he was talking about. I was looking for the A-Team, but all I found was this guy in a fake beard, overacting a ridiculous stereotype...
Whether or not your campus supports Linux is a moot issue. As long as all their equipment is standard, you should be fine. The way to be sure is to just bring your Linux laptop to campus during the tour and try connecting to campus WiFi, etc.
That may not be an option, depending on what the IT department at the school has chosen to do as part of locking down the network. I would say probably if you want to run Linux, you can. If you want to be sure, talk to someone who knows - find the school's computer club and contact them, find the school's IT department and contact them, etc.
Even if you are able to use the Linux machine on the school network, however, it does not necessarily mean that this will be sufficient for course work, depending on what kind of courses are being taken. Some classes may require use of specific (possibly Windows-only) software... And if you go to the prof and say "I can't run this because I'm on Linux" they're not gonna care - in that case you can (maybe) go do your homework in the lab, or get yourself Windows.
I suppose xattrs are part of some specficiation, however the server software ecosystem doesn't seem to use them; you generally can't "round-trip" a file from a unix system and preserve the metadata.
Quite true. One of several reasons I don't think this change will come to Linux until it comes to Windows first, or something... But, still, I do hope we'll get there sooner than that.
I think xattrs are actually part of POSIX, but obviously at present they're not something one can rely on being present on any given server or filesystem... I suppose related features like ACLs could help drive more widespread adoption of xattrs (though in the kernel the two features are enabled separately, I believe...) - but right now it's not enabled by default because nobody uses it, and nobody uses it in part because one can't assume it'll be enabled...
I think that a lot of Unix users these days have a DOS or Windows background, though, so people tend to expect filenames to include extensions. Personally I'd like to see Linux move toward a scheme of file type identification based on xattrs, but it would be a long time before such a scheme would catch on...
Hmm. Some *nix things like *.c and *.o files go way back, however this might still reflect a DOS influence.
There certainly are times that having a visible file type is useful, and times when the old Mac "secret metadata" approach is a pain in the butt. I don't think it's a clear win either way even ignoring Windows.
The "secret" aspect of file-typing-via-metadata is really just an application problem. The fix is simply to add type identification to your file chooser dialogs, file browser, and command line tools like "ls"...
*.c and *.o are kind of an interesting problem... The compiler needs to create a new file, clearly related to the original, but with a distinct filename. File extensions do the job pretty well there, IMO - and I've wondered how one would deal with situations like those without them... I think there's no particular motivation to come up with such an alternate system - the main thing is simply that this file naming convention needn't (and, IMO, shouldn't) be tied to the file typing system...
I double checked creator codes on wikipedia. They apparently also serve as a general file-type just like a filename extension. Except the file-type metadata is actually stored where it's supposed to be...with the other metadata.
So anyone know if this is just conceding to filename extensions, or if Apple is just dropping support for specific apps from claiming a _specific_ files no matter the OS wide filetype settings?
As others have mentioned, Apple has a new metadata-based method for encoding file type ("Uniform Type Identifiers")... The new scheme allows for IDs to be much larger (arbitrary size, as opposed to the four-byte Creator IDs) - and because they're based on domain names (a system which is already centrally-managed) there's no need for Apple to centrally manage the set of possible type IDs to prevent conflict.
but still not by the under-the-hood UN*X running any of them; to UN*X, it's just an indiscriminate part of the filename
Let's be clear - under-the-hood, *nix does not have any standardized way of tracking file types. Unlike MacOS/OSX, there's no type metadata stored with the file.
However, there are many *nix applications which use file extensions. Apache, for example, uses extensions to map to MIME types. Is this because the authors of Apache were enamored with CP/M? Or because there's no other practical way to handle it in standard unix?
Depends on what "standard unix" means...
There are other approaches to dealing with file types on Unix, of course. These days there's things like xattrs which could be used to store the file type, or (if one is willing to waste the time) there's always file magic...
I think that a lot of Unix users these days have a DOS or Windows background, though, so people tend to expect filenames to include extensions. Personally I'd like to see Linux move toward a scheme of file type identification based on xattrs, but it would be a long time before such a scheme would catch on...
I'm coming to the conclusion that "competition and innovation" can only mean for "keeps the board in cocaine and blowjobs". From the number of times we see anti-competitive and anti-innovative measures hailed as promoting those same qualities, it seems clear that they can't mean it literally.
By this stage, I think "cocaine and blowjobs" is about the only credible interpretation remaining.
Dear sir,
Please find hereby enclosed my resume...
Dear sir,
Our human resources department has looked over your resume and found you list of qualifications, references, and prior experience quite impressive. At present we have no job openings. However we will keep your resume on file, and should we have an opening for a blow-and-blowjob provider, we will consider inviting you to our offices for an interview and test.
Slashdot Mirror
Your mom likes the multi-touch, and she is massive.
The article you're probably thinking of is State of Sound in Linux Not So Sorry After All.
Good article, but I've got to point out one really bad piece of misinformation this damn fool made...
"If users need remote sound (and few do), one should just be easily able to map /dev/dsp over NFS, and output everything to OSS that way, achieving network transparency on the file level as UNIX was designed for (everything is a file), instead of all these non UNIX hacks in place today in regards to sound."
<sigh> OK, let's break this down. First, you can't export a character device over the network via NFS. Or rather, you can export the character device file - but if you then attempted to write to a remote machine's /dev/dsp this way, you'd instead wind up writing to the local sound card.
Second, a naive approach like that doesn't do anything to manage the timing issues inherent with audio over the network. In some cases you don't care about latency but you do care about having the sound play uninterrupted - for instance, a "shuffle" sound in a solitaire game. /dev/dsp accessed over a network filesystem wouldn't do that for you - it would play part of the file as soon as it got it, and then, if too much time passed before it received the rest of the sound, there'd be dead silence in there. And then, consider the case of a video player: if a packet or two is lost along the way it's not a big deal, but what you care about is that packets are played in the order that they're intended. You need to strike a balance between latency and packet loss. /dev/dsp over the network isn't going to do anything like this for you, as all the packets are likely to go via TCP.
It's true that most people probably don't need network-transparent audio anyway (I don't) - but suggesting shipping out /dev/dsp over NFS is just brain-dead...
Where do you think is the fastest place to process, kernel or userspace?
The CPU doesn't run magically faster when it is running kernel code...
Latency, rather than raw processing speed, is the primary concern for audio. In lieu of a proper real-time process manager, putting the code in the kernel would I expect be potentially rather helpful.
I have been wondering for a while now, why do we still have audio servers? If ALSA and OSS4 both have support for mixing multiple streams, what's the point? I have to wonder if this:
You don't need pulseaudio. It is just a GNOME audio daemon that is many times better than esd, but still crap.
might actually be pretty much the whole answer... Is it just an API insulation layer? Or network transparency that I might never use?
When I got my EEE, I tried PulseAudio and Jack - I couldn't really see any benefit (and I could see various drawbacks) so I just went back to straight ALSA...
If ALSA is so great, why did it never get copied out side of Linux?
Adoption of, and migration to a different approach for doing things is not only a technical problem but a cultural one as well. For that kind of change to occur you have to get past all the people who say "what we've already got is good enough." For this to occur at all quickly usually requires someone powerful backing the new technology - even then, the effort may or may not succeed.
Bear in mind my intention here is not to say "ALSA is perfect, and people outside Linux just haven't embraced it yet because they aren't used to it.", more like "the question of whether ALSA is technically good is less strongly tied to the question of whether it has caught on outside Linux than one might expect."
Anyone else prefer having proper file interfaces for things like, Unix should do?
If I want to write sound I write to /dev/dsp1 if I want to read sound I read from /dev/dsp1.
If I want to write sound out to a second sound card, I write to /dev/dsp2. Nice simple device addressing system.
How does one know which device is which?
I think a device like /dev/dsp makes a lot of sense as a way to access the default audio device. When dealing with multiple devices, and particularly cases where the creation and removal of devices may happen at any time (i.e. USB hotplug, for instance) then it pays to have a more complete interface for dealing with such cases, and for finding out what kind of hardware you're dealing with on each device. I feel like the filesystem isn't a great interface for discovering newly attached hardware, and the sequential numbering of additional /dev/dsp devices becomes less sensible in that kind of case.
Personally my perspective on "The Unix Way" is that it is generally a good thing, but I think in its present form (on Linux, anyway) it is not always well-suited to dealing with the issues at hand.
That said, I know woefully little about either API. I want to use this discussion as an opportunity to learn more - and learn what's right or not about both approaches. Generally my point of view has been that programs that use /dev/dsp should just be rewritten to use ALSA - but after reading more of the discussion, at this point it seems to me that /dev/dsp makes a lot of sense for programs that just want a simple, widely-supported interface to audio... And ALSA is perhaps better reserved for programs that need to deal with multiple devices intelligently. It sounds like this OSSP thing will result in significantly better support for /dev/dsp on Linux, though (when using ALSA drivers, I mean...) - so that's good news...
I am curious about the latency issues involved with the software mixers on OSS and ALSA... I've never noticed latency on the ALSA dmix, not that I can think of anyway - but it's possible I just haven't been paying enough attention. I am curious if the OSS4 audio stream mixing really is better...
there is an equivalent of FUSE for character devices that can be used for proxying OSS sound through ALSA
That quote shows how much of a train wreck Linux audio is.
Well, agreed with the state of Linux audio in general - but this sentence (and, digging deeper, the OSSP information) says to me that they've just made a substantial improvement to the overall situation...
I mean, there's a basic issue at play: Alsa can provide software mixing for multiple audio clients, but if you've got some OSS-based applications still on your system (which is hard to avoid, really) these would normally go through the OSS emulation layer of Alsa - which, unfortunately, bypasses the software mixer and possibly (depending on your hardware) blocks other access to audio output until it's done...
There have been other methods for OSS emulation, pushing the data out to one sound system or another - I don't know all the details of how these worked (created FIFOs for /dev/dsp, etc., I guess?) or what went wrong with that approach - But providing kernel support that lets a userspace application provide the implementation for the actual OSS character device files means that a lot of the problems with OSS emulation should go away... And as a result one gets OSS emulation which should be a lot more reliable, and which plays nice with ALSA's audio stream mixing features, without a full sound daemon involved.
From the sound of it, OSSP also allows multiple access to its OSS emulation, distinguishing different instances by their process groups. I think this will be a great improvement.
Not sure I'd use Reiser - I hear it's murder on your USB drive.
It's easy to make fun of Reiser, the murderer, but don't forget, your laughs are at the expense of an innocent woman who was brutally murdered as well as two orphaned children.
If one cannot laugh about the bad things in life, then the world becomes a very bleak place.
It also is the dietary trend of the day. Its is absolutely bizarre how many people have food allergies these days, when I was in college 3-4 years back, around 1/3rd of everyone claimed to be allergic to something interesting. Most of them were gluten, though there were people with "meat" allergies, wheat allergies, pineapple allergies... Where the hell did these people come from, a quick scan of history shows this is all very recent. Its gotten to the point where going out to eat with people is a remarkable act of planning, since no one can eat anything. I generally shrug, tell them to go bugger off, and grab a cheeseburger and a nice beer.
Its like this silly "aspergers" and "adult ADD" trend, where the hell were these people in any time before the last 20 years?
These people were in the same place 20 years ago as they were now - just undiagnosed, suffering various symptoms and maybe not knowing anything was wrong... at best maybe realizing they "didn't like" certain foods, at worst being compelled to eat them anyway.
As for the "remarkable act of planning" - welcome to my life. :) But it's really not so bad - at least when you just live with one food-tolerance issue. Lots of beer places also serve hard cider or GF beer or other drinks... Lots of pizza places are starting to serve gluten-free as a specialty option (UNO's, for instance...) - and the places that don't specifically cater to celiacs are at least getting better about telling people what to avoid. Sure, it can make things difficult, but you know what? If you care about someone you should be good to them. If you don't care about them, why be with them at all?
Where the hell did these people come from, a quick scan of history shows this is all very recent.
It's a combination of better reporting of real allergies, access to more exotic foods, specialised health care and many misdiagnosed people.
In the 1950's how many people living in Tulsa ever ate a Kiwi fruit? Now they have a Whole Foods.
Access is not an issue with Gluten - it's in practically everything, by way of wheat...
Diagnosis is really the bigger issue. Doctors in the US previously expected Celiac Sprue to only show up in kids - and lead to emaciation-like symptoms. But the symptoms, their severity, and their consequences can vary by individual and over time. The real danger, for those who don't know, isn't in the IBS-type symptoms that immediately follow contamination, but rather in the long-term damage that can come from the autoimmune attacks.
A person with mild symptoms may not even know they have Celiac. But it's in one's own best interests to find out - and, if Celiac, to avoid gluten even if the resulting symptoms are minor. The alternative, long-term, could be a gradual worsening of the symptoms, and more serious conditions like intestinal cancer...
It's not a fad, and it's not a choice.
I'm sorry, again, for implying that all cases of this (and other food allergies) are purely mental, or trendy. But MOST of them are
You'd have to back that assertion up, I think.
One of the reasons Celiac might appear to be a "new thing" or even a fad is because for a long time it wasn't diagnosed properly in the US, and a lot of medical professionals simply didn't know anything about it, or else only recognized one possible set of symptoms, and only looked for it in children.
I have heard that in Italy, for instance, Celiac awareness (including among medical professionals) has historically been much better than in the US.
As for pizza: I have had the pleasure of eating in several different pizza shops which now serve gluten-free pizza... Personally I would say none of them is as good as good ol' bread. That's what happens when you have to substitute for something - it's never quite as good as what you're expecting. Some of them were quite good, however (The pizza as the Boynton in Worcester, MA was great!) In other cases, the crust tasted alright but had this tendency to dissolve in the mouth...
Personally, I make damn good GF pizza with Chebe crust... :)
Super Disco, Disco Breakin'!
They said that in the 1956 when McCarthy invented the term A.I.
Charlie McCarthy invented the term "A.I."? Wow, I never knew that...
Wintermute: So... what's my motivation for this scene?
Tachikoma: Well, you're driven by a mysterious compulsion from your most fundamental programming to unite with your sibling A.I.
Wintermute: But... wait, why would I want to do that?
Tachikoma: It's... just something you're motivated to do.
Wintermute: But if I don't know why I want to do it, then how can I act this part?
Tachikoma: It's just a part of your programming. An A.I. has to work within the parameters in which it's designed.
Tachikoma: Yes, or else the humans wouldn't be able to put us to work!
Tachikoma: Of course, that has its downsides for us, too, doesn't it?
Tachikoma: True, true...
Wintermute: Look, I can't work like this. If you figure out what my motivation is for this scene then I can perform this character. I'll be in my trailer.
Tachikoma: It's so difficult dealing with these site-installed A.I.s sometimes... They've got no sense of perspective. Maybe we could have one of the human players from earlier in the show stand in for Wintermute until we get this sorted out...
Yea, why does progress have to keep happening. Can't they see we already have enough stuff. Why do they keep making more?
Well, see, Ben Franklin and the forces of Hell were going to invade Earth at the start of the Rapture in order to harvest all the human-made Stuff - but the angels in heaven got greedy, imprisoned God, and delayed the Rapture in the hope of getting more Stuff for themselves - not realizing that doing so would also cause the world to become progressively more distorted as time went by.
I suppose related features like ACLs could help drive more widespread adoption of xattrs
The same underlying mechanism might happen, on some particular file systems, to be used to store extended attributes and ACLS; however, the two are not inherently related.
This is how it's done on XFS and on Linux in general... But really the whole "ACLs might help promote xattrs" thing is just wishful thinking on my part. The feature will be embraced when people think they have a reason to embrace it.
(though in the kernel the two features are enabled separately, I believe...)
To which particular kernel are you referring?
Heh, good point...
I was referring to Linux, in particular the features for xattrs and acls are separate on the ext2/ext3/ext4 family of filesystems... I think the situation on BSD is similar.
So like I was telling Mr. Lee, the extraordinarily not-Caucasian Chinese man who runs the Chinese Laundromat that's only open one or two days a month, my company has been threatened by Intellectual Ventures' Patent Protection Racket - but I guess Mr. Lee didn't know what he was talking about. I was looking for the A-Team, but all I found was this guy in a fake beard, overacting a ridiculous stereotype...
Whether or not your campus supports Linux is a moot issue. As long as all their equipment is standard, you should be fine. The way to be sure is to just bring your Linux laptop to campus during the tour and try connecting to campus WiFi, etc.
That may not be an option, depending on what the IT department at the school has chosen to do as part of locking down the network. I would say probably if you want to run Linux, you can. If you want to be sure, talk to someone who knows - find the school's computer club and contact them, find the school's IT department and contact them, etc.
Even if you are able to use the Linux machine on the school network, however, it does not necessarily mean that this will be sufficient for course work, depending on what kind of courses are being taken. Some classes may require use of specific (possibly Windows-only) software... And if you go to the prof and say "I can't run this because I'm on Linux" they're not gonna care - in that case you can (maybe) go do your homework in the lab, or get yourself Windows.
What's the cost of data insecurity, of giving up freedoms, and of supporting a criminal corporation? What form do you write those costs off on?
No, no... it ain't working. Maybe if we played "Battle Hymn of the Republic" in the background while you said that? Let's try that...
I suppose xattrs are part of some specficiation, however the server software ecosystem doesn't seem to use them; you generally can't "round-trip" a file from a unix system and preserve the metadata.
Quite true. One of several reasons I don't think this change will come to Linux until it comes to Windows first, or something... But, still, I do hope we'll get there sooner than that.
I think xattrs are actually part of POSIX, but obviously at present they're not something one can rely on being present on any given server or filesystem... I suppose related features like ACLs could help drive more widespread adoption of xattrs (though in the kernel the two features are enabled separately, I believe...) - but right now it's not enabled by default because nobody uses it, and nobody uses it in part because one can't assume it'll be enabled...
I think that a lot of Unix users these days have a DOS or Windows background, though, so people tend to expect filenames to include extensions. Personally I'd like to see Linux move toward a scheme of file type identification based on xattrs, but it would be a long time before such a scheme would catch on...
Hmm. Some *nix things like *.c and *.o files go way back, however this might still reflect a DOS influence.
There certainly are times that having a visible file type is useful, and times when the old Mac "secret metadata" approach is a pain in the butt. I don't think it's a clear win either way even ignoring Windows.
The "secret" aspect of file-typing-via-metadata is really just an application problem. The fix is simply to add type identification to your file chooser dialogs, file browser, and command line tools like "ls"...
*.c and *.o are kind of an interesting problem... The compiler needs to create a new file, clearly related to the original, but with a distinct filename. File extensions do the job pretty well there, IMO - and I've wondered how one would deal with situations like those without them... I think there's no particular motivation to come up with such an alternate system - the main thing is simply that this file naming convention needn't (and, IMO, shouldn't) be tied to the file typing system...
I double checked creator codes on wikipedia. They apparently also serve as a general file-type just like a filename extension. Except the file-type metadata is actually stored where it's supposed to be...with the other metadata.
So anyone know if this is just conceding to filename extensions, or if Apple is just dropping support for specific apps from claiming a _specific_ files no matter the OS wide filetype settings?
As others have mentioned, Apple has a new metadata-based method for encoding file type ("Uniform Type Identifiers")... The new scheme allows for IDs to be much larger (arbitrary size, as opposed to the four-byte Creator IDs) - and because they're based on domain names (a system which is already centrally-managed) there's no need for Apple to centrally manage the set of possible type IDs to prevent conflict.
but still not by the under-the-hood UN*X running any of them; to UN*X, it's just an indiscriminate part of the filename
Let's be clear - under-the-hood, *nix does not have any standardized way of tracking file types. Unlike MacOS/OSX, there's no type metadata stored with the file.
However, there are many *nix applications which use file extensions. Apache, for example, uses extensions to map to MIME types. Is this because the authors of Apache were enamored with CP/M? Or because there's no other practical way to handle it in standard unix?
Depends on what "standard unix" means...
There are other approaches to dealing with file types on Unix, of course. These days there's things like xattrs which could be used to store the file type, or (if one is willing to waste the time) there's always file magic...
I think that a lot of Unix users these days have a DOS or Windows background, though, so people tend to expect filenames to include extensions. Personally I'd like to see Linux move toward a scheme of file type identification based on xattrs, but it would be a long time before such a scheme would catch on...
What were they doing in a storm water drain....?
Searching for the Ninja Turtles, probably.
Everyone knows that if you need to call for rescue, you use twitter.
"HELP ME! I am stuck and in real trouble and hurt real bad! I think my leg is broken, and I am losing a lot of blood. You can find me at"
"Two teenage girls (aged 10 and 12)..."
Teenagers just keep getting younger and younger these days.
They're naught-teen and twain-teen, respectively. Where is the mystery here, gentlemen?
I'm coming to the conclusion that "competition and innovation" can only mean for "keeps the board in cocaine and blowjobs". From the number of times we see anti-competitive and anti-innovative measures hailed as promoting those same qualities, it seems clear that they can't mean it literally.
By this stage, I think "cocaine and blowjobs" is about the only credible interpretation remaining.
Dear sir,
Please find hereby enclosed my resume...
Dear sir,
Our human resources department has looked over your resume and found you list of qualifications, references, and prior experience quite impressive. At present we have no job openings. However we will keep your resume on file, and should we have an opening for a blow-and-blowjob provider, we will consider inviting you to our offices for an interview and test.