No, I don't. I'm looking for a mechanism that would prevent a specific act. I understand that this is double edged, since if said mechanism is possible, then it could be used to censor.
It would be great, in my mind, if there were no laws at all. Can you think of the inherent problems that causes?
People assume too much. --- script-fu:hash bang slash bin bash
I agree, actually. That's as far as I've gotten in my contemplation. Live with the risks. I am kind of selfish in the sense that I'm willing to risk damage to the world for things that I think will change it for the better, if successful.
I've come to this conclusion, just now. It's not the system (of anonymty) that has the fault. The fault is in other people. It's been too long that people can blame the environment for people's actions, and not the people themselves.
What actions are agreeable or not is in the eye of the beholder.
As much as this is flamebait, it is a question that needs asking.
Child Pornography is already a problem, predominantly on news spools (so I understand).
The design of FreeNet suggests that it could be used to publish some simply nasty stuff. I don't agree with censorship, I don't agree with the majority of laws, but I definitely don't agree with that kind of exploitation.
Is there any mechanism in FreeNet that will prevent this?
I'm asking this question for two reasons, first I believe it needs answering, and second, I'm developing an anonymity cooperative which will make it even easier for that sort of thing than FreeNet does, and if you have a solution, maybe it will work for my system also.
I have to agree, sort of. This won't test the whole of the GPL, it will test whether or not the GPL leagally means anything.
Sadly, I don't think it looks good for the GPL. I understand that the GLP *ought* to be enforceable, but there's a lot of laws that ought to be otherwise.
Regardless, I don't think the GPL will help these folks out. I laughed hard when I realized what they'd done, but then I thought about it, and it looks more live they've illegally signed an agreement to me. They get points for style though.
I agree, not any time soon. I do think that we humans will come to a point where we will create artificial consciousness, just not in my lifetime. That is, if we don't kill ourselves first.
Look at it this way: As a materialist, I say we're purely physical beings (if I'm wrong, I'll find out when I die, which will be a wonderfully pleasant suprise). Any magic you can throw into the mix is physical phenomena.
Humanity seems to be bent on progress of nothing as much as it is on sciences. One of those sciences is physics, the most low-level we have conception of. Right now, although the world is not ruled by robots, we've still got technologies that weren't thought possible 20-30 years ago.
Whether or not out current conception of physics is rock-bottom (i.e. you can dive no deeper), which I doubt it is, we still go deeper all the time. Classically, things were attributed to magic, we're finally getting down to analyzing that magic.
Since a biological process can create intelligent, sentient, conscious life with pure matter, couldn't an artificial method do the same, given the proper understanding? The only way to answer no, is to have some sort of soul-theory, where sentience is in the soul, and souls may only create new ones by 'due process'. But I don't buy that. I don't buy souls at all, in the Christian sense.
So, I say, yeah, it will likely happen, but not anytime soon. I hope I'm wrong and it happens tomorrow (I stocked up on red pills from Nitrozac <G>)
I think the dividing line here is what you're doing with your music. I do both home recording and live. I need a few cheap boxes for shows -- you don't really need fully-functional realtime for anything else (but it can be quite nice).
I can't spend a lot of money on computers. At the same time, part of this whole rant is this: legacy realtime apps have been written in ASM, and thus cannot be easily ported to Linux.
Personally, I believe that mixing routines should be written in ASM regardless -- but they don't need to be in the app. Throw them in a library somewhere.
This just applies to my situation. I know a lot of people in this situation. Most of my musical friends have no computers and little money. They're interested in using computers for backup. The only solution for them is something cheap.
Sadly, I don't have all I need. I need to be able to code in the environment I'm using for real time audio. I started coding in Linux and it spoiled me, I won't touch DOS now... I like to write programs quickly to do little jobs.
Despite what a lot of people believe, I do believe that efficiency must be kept up in the core of real-time apps. Remember when this stuff was done on Amigas? Nine Inch Nails used an Amiga last I checked.
I patently disagree. Buzz won't run on my 386 or my 486, therefore I can't take it with me, therefore it's not good enough for me.
ASM does improve mixing routines quite a bit. By comparing different apps (some in c, some in asm) on a low-end machine, you can see that ASM really makes a difference.
The thing is, I can buy a tracking box and use traditional stuff on it for very little, if I use mostly ASM based apps. Otherwise it's going to cost me how much? I can get a hardware sequencer cheaper than I can get a fully-functional PIII.
One big problem I've noticed in real time audio for Linux lies in the code. Decent trackers for DOS are written in 90-100% assembly. It seems no one who does sound development for Linux is prepared to write a lot of assembly routines.
There's a real-time virtual 8-track called Goat Studio (or Goat Tape, by some) that come with the source. It's for DOS, and it's got a chunk of assembly in it. I would port it, but I'd have to learn two styles of ASM for the x86 -- which I don't have time to do. Goat Studio is very useful for laying down tracks, since it uses full duplex to play the non-muted tracks for you while you record one. The only physical limitation is that you can only record one track at a time, but this won't concern most solitary musicians.
Back to the point. Many real-time apps must be written in ASM since the processing has to be fast, perhaps you can get away with C these days, since we're no longer dealing with 386s, but PII/400s -- but I still keep a 386 with a tracker and some other stuff on it to bring to tracking parties (like MGF). I'm not going to take my best box on the road with me if I'm going to need it for something else, but a 386 or 486 plus a soundcard I can pick up for nothing. --- script-fu:hash bang slash bin bash
I definitely intend to take a look. I haven't been looking so much lately. I read about this in a previous comment and bookmarked it right away.
The flazicator is brain-dead simple, but it can produce the coolest effects. I'd like to build a hardware flazicator someday for live processing. Anyhow, I'll happily release the source to it, but be warned it's a bit of a hack, and it only operates on 8bit/raw samples.
I spent some time trying to work on a sample-mangling library. I found I just don't have the time to work on it. Also, there's a few things I'm not exactly a god at that I need to learn (half the fun). I managed to write formulaic wave generators (sin/cos/tan/sqr/triangle/rising saw), and the odd effect. The only thing that was of any real use was what I'd called the 'flazicator', which would make a sample sound like the freaky voice parts of "it doesn't matter" (Dig Your own Hole/Chemical Brothers).
Does a sample processing library exist already? I haven't seen one. I think this would speed things up, since this kind of code would be common to all of these audio projects... pure MIDI not withstanding.
Something I personally need is a mod tracker. There aren't any decent trackers, as far as I have found, for Linux. Impulse Tracker is the sole reason I keep a DOS partition, it's simply the best tracker, IMHO. These days, it seems trackers are falling out of popularity, and those still being developed are crossing the line, into bigger and better editing suites.
Unix hasn't completed it's development cycle yet. I doubt it will until long after it dies -- if it dies before humankind.
I do believe it was 1971 when the first Unix system went online -- back when 'online' meant 'it works' (like the little green light on your printer).
Unix itself, as in the general phenomenon (if you will), as opposed to 'AT&T Unix', the distribution, therefore has been in development for 30 years. Any form of it that stagnates, dies. This became inevitable when unicies with freely distributable source started appearing, people (especially unix users) tend to try to make things better, unless they're paid to do something different.
Kevin O'Brien once said this in response to someone going on about how unix was ancient, deprecated, and dead. Kevin also said "It's not smut, it's data," when the question of webspace contents came up =).
I wouldn't worry about Unix dying off for now. I won't live to see it, I'm sure of that much. There's obviously nothing around now that can kill it. I do believe that it would take an entirely different paradigm to kill Unix -- so micros~1 obviously won't manage to do it, since all they seem to be able to do is take two existing paradigms and make them both worse.
In regards to specific tasks, if a certain kind of task is popular, then (as usual) Unix will adapt to accomodate. Yes, I know there are things that unix cannot do, simply for lack of the appropriate software. But this isn't a technical fault, it's a social problem, as all the examples I can think of involve user-friendliness, idiot compliancy, and streaming media. Linux is getting closer to a desktop OS all the time. Personally I dislike this (I don't want to use what the end-users are using), but it's the truth.
IMHO, there's little one can do to ensure their privacy and anonymity. TrustE is only as good as the policy is, and the word of the licensee.
You won't get anything 100% with someone's policy or word. The only 100% is when it is physically impossible to violate privacy / anonymity.
Some of the mathematical theories I have faith in suggest that 100% privacy / anonymity is unattainable, but practically speaking, things like freedom and AT&T's Crowds is about as good as you'd ever want for the privacy / anonymity level provided.
Also, I'm working on an anonymity project, involving a cooperative network of computers to ambiguate the source. Many common services are possible, and their use is transparent (i.e. you can use pine, elm, kmail, netscape, or whatever you like for email). The link's in my.sig
Slackware is my distribution of choice for two main reasons, it's powerful, and it hasn't been poisoned by 'userfriendliness'.
Why hasn't it been? Seems every Linux distro (slackware aside) that's making money has made their distribution as brain-dead as possible. Where slackware users are expected to have an idea of what they're doing. Is it laziness, or is it out of respect for those who want a no-BS distro?
AAARRRHGHGHGHGH!!! Intuition != Familiarity. A baby has never seen a nipple, yet knows what to do: intuition. I know how to change my video driver in windows because I've done it millions of times: familiarity. These two things are not the same.
You're right, they're not the same, but I wasn't trying to say they were.
This is a bit difficult to explain. It's not that you're used to doing a certain thing, it's that when new things pop up you 'intuitively' know what to do -- it's how you behave. You're faced with an unprecedented situation, yet you still know what to do, just like the nipple. It happens all the time, with everyday life.
Even if you disagree with the word 'intuition' in this scenario, it's still not simply familiarity -- there's still rabbits coming out of hats, and if you look at why a child knows to take a nipple, you'll note that it's also an instinctual drive. Instinct being distinct from intuition as it is a pre-programmed assumption, intuition being more flexible.
Mandelbrot went on for the longest time about how he needed to 'create intuituition', and I think he had it right. --- script-fu:hash bang slash bin bash
Well, I agree with your spirit for maintaining functionality, but I disagree that intuitive interfaces do not exist.
The reason is this: intuition isn't in the tool, it's in the user. People do things with stuff, and when they complain that their stuff sucks, we tell them not to blame their tools.
Intuition is acquired. That's why people feel that M$ Windows is intuitive -- it's been the primary OS for PCs for quite some time now -- everyone's familiar with it.
A lot of command line tools are set-up to be intuitive. Think about it, have you ever discovered that something had readline support by hitting alt-backspace out of habit? It happens to me all the time (like this box textarea right here in netscape ^A, ^E, whee!)
This is how I believe things should be done, UI libs should standardize the general way UIs behave. Call it 'libnipple'.
Personally, I don't care about user-friendliness, since the command line is quite intuitive for me. It's because I learned to use it.
I know that not everyone wants to learn how to use a system. Linux developers can go ahead and try to please those who don't really get into their systems, I don't mind.
My concern is this: do I still get the old interface? Think about it. It's already happened. I'm using X right now, and it's hell, but there's apps for it that I need to use, ones that would otherwise be developed for the CLI that I love.
You have a point. Although, I haven't seen anything specifying exactly how 'makes' are supposed to function (possibly because I haven't looked).
I'll add that simply because one implementation of a standard isn't compatable with another, doesn't mean it's nonstandard -- just like we have with micros~1's implementation of Kerberos.
do I have to get permission from the FTC every time I want to sell or give away a piece of information I've collected?
If you're talking about personal information, then you might want to consider asking the permission of the people who you intend to exploit instead of the FTC. Da?
That's the problem. It still conforms to the standard. That's why the standards must change. I'm calling it 'an implementation of Kerberos' because that's technically what it is.
That's why I'm buggin' over it. They can call it Kerberos and no one can say boo. I/wish/ I could simply say "it's not/really/ kerberos", but I can't. Sigh.
There is a solution to this. Or at least to stop it from happening in the future.
Stadnards could be written in such a way that any extended features must be requested before thier use. If they aren't available, then the client / server MUST continue without the use of that extended feature.
This would eliminate incompatabilities like this, since any closed (or otherwise) implementation that doesn't function without a certain extended feature could not claim to conform to the standard. At this point micros~1 could not claim they've got an 'enhanced implementation of standard X' when their version is incompatable with everyone else's. They could only claim to have an 'incomplete implementation of standard X'. The key is placing portability implicitly in the standard.
In defence, people mentioned Linux and nothing else because they don't use anything else. For the most part they've been windows users that finally started using a real OS. They've never touched anything like Unix other than Linux. Simply they are naive. They don't mean any harm to BSD (I hope) or other OSS OSs, they simply aren't worried about them.
I'm glad you made the point that a lot of Linux development is NOT non-profit, which is why I'm not so worried about Linux USB support -- (say) RedHat will be the first to get it, and they'll make money from it, then the rest will have it, and all is well.
This is just speculation, I don't know that the masses think this way, but they sure seem to. If it isn't the case, and they HAVE been dependant at one point or another on something else, they have no excuse.
I agree. On top of that, don't worry about it. I've seen several PC Repair Kits with magnetised screwdrivers, in fact I've used them without any dataloss. This won't be a problem.
Aye, it is a great book. I loved reading the book, up until the end, I hated the ending. It just seemed plain old lame to me. But the book was still very much worth reading, like H2G2, I stayed up all night 'til I finished it. --- script-fu:hash bang slash bin bash
Project Mass Confusion
on
A New DeCSS
·
· Score: 1
Every interested software developer could release a 'DeCSS' release of anything they release in the next little while.
A DeCSS Linux distro could be formed.
Any other ideas? --- This machine is obsolete - Trent Reznor, 1999
Personally, I hate package managers. I don't feel comfy with anything other than tar and gzip. The reason is, I need control. Which is why I won't use GUIs unless I have to (i.e. to read slashdot).
I'm a slackware user (no holy wars!), and I can live with pkgtool because it's really just a glorified version of 'cd/;tar xfz foo.tgz; cd -'. You know where everything is, and you know that you can remove it -by hand- and it won't screw anything up.
The only exception I give to this is the CPAN module for perl. The only reason why I'm willing to use it is that I *know* I'll never remove a perl module.
I'll probably get nailed by the user-friendliness advocates. I'm sorry, I don't like macs, GUIs or mice. I think of user-friendliness as idiot-compliancy. It wasn't allways that bad, but seriously, Microsoft et al. have reduced themselves to the lowest common denominator, which is a blundering idiot. I dispise this practice, and I see it happening in the Linux community, which makes me cry. But c'est la vie, besides, I can turn off inetd, rewrite the inittab, and the.rc files. And I can change root's profile so that rm isn't executed with -i by default (although I don't have to, 'cause I won't use RH).
Slashdot Mirror
No, I don't. I'm looking for a mechanism that would prevent a specific act. I understand that this is double edged, since if said mechanism is possible, then it could be used to censor.
It would be great, in my mind, if there were no laws at all. Can you think of the inherent problems that causes?
People assume too much.
---
script-fu: hash bang slash bin bash
I agree, actually. That's as far as I've gotten in my contemplation. Live with the risks. I am kind of selfish in the sense that I'm willing to risk damage to the world for things that I think will change it for the better, if successful.
I've come to this conclusion, just now. It's not the system (of anonymty) that has the fault. The fault is in other people. It's been too long that people can blame the environment for people's actions, and not the people themselves.
What actions are agreeable or not is in the eye of the beholder.
---
script-fu: hash bang slash bin bash
As much as this is flamebait, it is a question that needs asking.
Child Pornography is already a problem, predominantly on news spools (so I understand).
The design of FreeNet suggests that it could be used to publish some simply nasty stuff. I don't agree with censorship, I don't agree with the majority of laws, but I definitely don't agree with that kind of exploitation.
Is there any mechanism in FreeNet that will prevent this?
I'm asking this question for two reasons, first I believe it needs answering, and second, I'm developing an anonymity cooperative which will make it even easier for that sort of thing than FreeNet does, and if you have a solution, maybe it will work for my system also.
---
script-fu: hash bang slash bin bash
I have to agree, sort of. This won't test the whole of the GPL, it will test whether or not the GPL leagally means anything.
Sadly, I don't think it looks good for the GPL. I understand that the GLP *ought* to be enforceable, but there's a lot of laws that ought to be otherwise.
Regardless, I don't think the GPL will help these folks out. I laughed hard when I realized what they'd done, but then I thought about it, and it looks more live they've illegally signed an agreement to me. They get points for style though.
---
script-fu: hash bang slash bin bash
I agree, not any time soon. I do think that we humans will come to a point where we will create artificial consciousness, just not in my lifetime. That is, if we don't kill ourselves first.
Look at it this way: As a materialist, I say we're purely physical beings (if I'm wrong, I'll find out when I die, which will be a wonderfully pleasant suprise). Any magic you can throw into the mix is physical phenomena.
Humanity seems to be bent on progress of nothing as much as it is on sciences. One of those sciences is physics, the most low-level we have conception of. Right now, although the world is not ruled by robots, we've still got technologies that weren't thought possible 20-30 years ago.
Whether or not out current conception of physics is rock-bottom (i.e. you can dive no deeper), which I doubt it is, we still go deeper all the time. Classically, things were attributed to magic, we're finally getting down to analyzing that magic.
Since a biological process can create intelligent, sentient, conscious life with pure matter, couldn't an artificial method do the same, given the proper understanding? The only way to answer no, is to have some sort of soul-theory, where sentience is in the soul, and souls may only create new ones by 'due process'. But I don't buy that. I don't buy souls at all, in the Christian sense.
So, I say, yeah, it will likely happen, but not anytime soon. I hope I'm wrong and it happens tomorrow (I stocked up on red pills from Nitrozac <G>)
---
script-fu: hash bang slash bin bash
I think the dividing line here is what you're doing with your music. I do both home recording and live. I need a few cheap boxes for shows -- you don't really need fully-functional realtime for anything else (but it can be quite nice).
I can't spend a lot of money on computers. At the same time, part of this whole rant is this: legacy realtime apps have been written in ASM, and thus cannot be easily ported to Linux.
Personally, I believe that mixing routines should be written in ASM regardless -- but they don't need to be in the app. Throw them in a library somewhere.
This just applies to my situation. I know a lot of people in this situation. Most of my musical friends have no computers and little money. They're interested in using computers for backup. The only solution for them is something cheap.
Sadly, I don't have all I need. I need to be able to code in the environment I'm using for real time audio. I started coding in Linux and it spoiled me, I won't touch DOS now... I like to write programs quickly to do little jobs.
Despite what a lot of people believe, I do believe that efficiency must be kept up in the core of real-time apps. Remember when this stuff was done on Amigas? Nine Inch Nails used an Amiga last I checked.
---
script-fu: hash bang slash bin bash
I patently disagree. Buzz won't run on my 386 or my 486, therefore I can't take it with me, therefore it's not good enough for me.
ASM does improve mixing routines quite a bit. By comparing different apps (some in c, some in asm) on a low-end machine, you can see that ASM really makes a difference.
The thing is, I can buy a tracking box and use traditional stuff on it for very little, if I use mostly ASM based apps. Otherwise it's going to cost me how much? I can get a hardware sequencer cheaper than I can get a fully-functional PIII.
---
script-fu: hash bang slash bin bash
One big problem I've noticed in real time audio for Linux lies in the code. Decent trackers for DOS are written in 90-100% assembly. It seems no one who does sound development for Linux is prepared to write a lot of assembly routines.
There's a real-time virtual 8-track called Goat Studio (or Goat Tape, by some) that come with the source. It's for DOS, and it's got a chunk of assembly in it. I would port it, but I'd have to learn two styles of ASM for the x86 -- which I don't have time to do. Goat Studio is very useful for laying down tracks, since it uses full duplex to play the non-muted tracks for you while you record one. The only physical limitation is that you can only record one track at a time, but this won't concern most solitary musicians.
Back to the point. Many real-time apps must be written in ASM since the processing has to be fast, perhaps you can get away with C these days, since we're no longer dealing with 386s, but PII/400s -- but I still keep a 386 with a tracker and some other stuff on it to bring to tracking parties (like MGF). I'm not going to take my best box on the road with me if I'm going to need it for something else, but a 386 or 486 plus a soundcard I can pick up for nothing.
---
script-fu: hash bang slash bin bash
I definitely intend to take a look. I haven't been looking so much lately. I read about this in a previous comment and bookmarked it right away.
The flazicator is brain-dead simple, but it can produce the coolest effects. I'd like to build a hardware flazicator someday for live processing. Anyhow, I'll happily release the source to it, but be warned it's a bit of a hack, and it only operates on 8bit/raw samples.
Feel free to email me.
---
script-fu: hash bang slash bin bash
I spent some time trying to work on a sample-mangling library. I found I just don't have the time to work on it. Also, there's a few things I'm not exactly a god at that I need to learn (half the fun). I managed to write formulaic wave generators (sin/cos/tan/sqr/triangle/rising saw), and the odd effect. The only thing that was of any real use was what I'd called the 'flazicator', which would make a sample sound like the freaky voice parts of "it doesn't matter" (Dig Your own Hole/Chemical Brothers).
Does a sample processing library exist already? I haven't seen one. I think this would speed things up, since this kind of code would be common to all of these audio projects... pure MIDI not withstanding.
Something I personally need is a mod tracker. There aren't any decent trackers, as far as I have found, for Linux. Impulse Tracker is the sole reason I keep a DOS partition, it's simply the best tracker, IMHO. These days, it seems trackers are falling out of popularity, and those still being developed are crossing the line, into bigger and better editing suites.
---
script-fu: hash bang slash bin bash
Unix hasn't completed it's development cycle yet. I doubt it will until long after it dies -- if it dies before humankind.
I do believe it was 1971 when the first Unix system went online -- back when 'online' meant 'it works' (like the little green light on your printer).
Unix itself, as in the general phenomenon (if you will), as opposed to 'AT&T Unix', the distribution, therefore has been in development for 30 years. Any form of it that stagnates, dies. This became inevitable when unicies with freely distributable source started appearing, people (especially unix users) tend to try to make things better, unless they're paid to do something different.
Kevin O'Brien once said this in response to someone going on about how unix was ancient, deprecated, and dead. Kevin also said "It's not smut, it's data," when the question of webspace contents came up =).
I wouldn't worry about Unix dying off for now. I won't live to see it, I'm sure of that much. There's obviously nothing around now that can kill it. I do believe that it would take an entirely different paradigm to kill Unix -- so micros~1 obviously won't manage to do it, since all they seem to be able to do is take two existing paradigms and make them both worse.
In regards to specific tasks, if a certain kind of task is popular, then (as usual) Unix will adapt to accomodate. Yes, I know there are things that unix cannot do, simply for lack of the appropriate software. But this isn't a technical fault, it's a social problem, as all the examples I can think of involve user-friendliness, idiot compliancy, and streaming media. Linux is getting closer to a desktop OS all the time. Personally I dislike this (I don't want to use what the end-users are using), but it's the truth.
---
script-fu: hash bang slash bin bash
IMHO, there's little one can do to ensure their privacy and anonymity. TrustE is only as good as the policy is, and the word of the licensee.
.sig
You won't get anything 100% with someone's policy or word. The only 100% is when it is physically impossible to violate privacy / anonymity.
Some of the mathematical theories I have faith in suggest that 100% privacy / anonymity is unattainable, but practically speaking, things like freedom and AT&T's Crowds is about as good as you'd ever want for the privacy / anonymity level provided.
Also, I'm working on an anonymity project, involving a cooperative network of computers to ambiguate the source. Many common services are possible, and their use is transparent (i.e. you can use pine, elm, kmail, netscape, or whatever you like for email). The link's in my
---
script-fu: hash bang slash bin bash
Slackware is my distribution of choice for two main reasons, it's powerful, and it hasn't been poisoned by 'userfriendliness'.
Why hasn't it been? Seems every Linux distro (slackware aside) that's making money has made their distribution as brain-dead as possible. Where slackware users are expected to have an idea of what they're doing. Is it laziness, or is it out of respect for those who want a no-BS distro?
---
script-fu: hash bang slash bin bash
AAARRRHGHGHGHGH!!! Intuition != Familiarity. A baby has never seen a nipple, yet knows what to do: intuition. I know how to change my video driver in windows because I've done it millions of times: familiarity. These two things are not the same.
You're right, they're not the same, but I wasn't trying to say they were.
This is a bit difficult to explain. It's not that you're used to doing a certain thing, it's that when new things pop up you 'intuitively' know what to do -- it's how you behave. You're faced with an unprecedented situation, yet you still know what to do, just like the nipple. It happens all the time, with everyday life.
Even if you disagree with the word 'intuition' in this scenario, it's still not simply familiarity -- there's still rabbits coming out of hats, and if you look at why a child knows to take a nipple, you'll note that it's also an instinctual drive. Instinct being distinct from intuition as it is a pre-programmed assumption, intuition being more flexible.
Mandelbrot went on for the longest time about how he needed to 'create intuituition', and I think he had it right.
---
script-fu: hash bang slash bin bash
Well, I agree with your spirit for maintaining functionality, but I disagree that intuitive interfaces do not exist.
The reason is this: intuition isn't in the tool, it's in the user. People do things with stuff, and when they complain that their stuff sucks, we tell them not to blame their tools.
Intuition is acquired. That's why people feel that M$ Windows is intuitive -- it's been the primary OS for PCs for quite some time now -- everyone's familiar with it.
A lot of command line tools are set-up to be intuitive. Think about it, have you ever discovered that something had readline support by hitting alt-backspace out of habit? It happens to me all the time (like this box textarea right here in netscape ^A, ^E, whee!)
This is how I believe things should be done, UI libs should standardize the general way UIs behave. Call it 'libnipple'.
---
script-fu: hash bang slash bin bash
Personally, I don't care about user-friendliness, since the command line is quite intuitive for me. It's because I learned to use it.
I know that not everyone wants to learn how to use a system. Linux developers can go ahead and try to please those who don't really get into their systems, I don't mind.
My concern is this: do I still get the old interface? Think about it. It's already happened. I'm using X right now, and it's hell, but there's apps for it that I need to use, ones that would otherwise be developed for the CLI that I love.
---
script-fu: hash bang slash bin bash
You have a point. Although, I haven't seen anything specifying exactly how 'makes' are supposed to function (possibly because I haven't looked).
I'll add that simply because one implementation of a standard isn't compatable with another, doesn't mean it's nonstandard -- just like we have with micros~1's implementation of Kerberos.
---
script-fu: hash bang slash bin bash
do I have to get permission from the FTC every time I want to sell or give away a piece of information I've collected?
If you're talking about personal information, then you might want to consider asking the permission of the people who you intend to exploit instead of the FTC. Da?
---
script-fu: hash bang slash bin bash
That's the problem. It still conforms to the standard. That's why the standards must change. I'm calling it 'an implementation of Kerberos' because that's technically what it is.
/wish/ I could simply say "it's not /really/ kerberos", but I can't. Sigh.
That's why I'm buggin' over it. They can call it Kerberos and no one can say boo. I
---
script-fu: hash bang slash bin bash
There is a solution to this. Or at least to stop it from happening in the future.
Stadnards could be written in such a way that any extended features must be requested before thier use. If they aren't available, then the client / server MUST continue without the use of that extended feature.
This would eliminate incompatabilities like this, since any closed (or otherwise) implementation that doesn't function without a certain extended feature could not claim to conform to the standard. At this point micros~1 could not claim they've got an 'enhanced implementation of standard X' when their version is incompatable with everyone else's. They could only claim to have an 'incomplete implementation of standard X'. The key is placing portability implicitly in the standard.
---
script-fu: hash bang slash bin bash
In defence, people mentioned Linux and nothing else because they don't use anything else. For the most part they've been windows users that finally started using a real OS. They've never touched anything like Unix other than Linux. Simply they are naive. They don't mean any harm to BSD (I hope) or other OSS OSs, they simply aren't worried about them.
I'm glad you made the point that a lot of Linux development is NOT non-profit, which is why I'm not so worried about Linux USB support -- (say) RedHat will be the first to get it, and they'll make money from it, then the rest will have it, and all is well.
This is just speculation, I don't know that the masses think this way, but they sure seem to. If it isn't the case, and they HAVE been dependant at one point or another on something else, they have no excuse.
---
script-fu: hash bang slash bin bash
I agree. On top of that, don't worry about it. I've seen several PC Repair Kits with magnetised screwdrivers, in fact I've used them without any dataloss. This won't be a problem.
---
script-fu: hash bang slash bin bash
Aye, it is a great book. I loved reading the book, up until the end, I hated the ending. It just seemed plain old lame to me. But the book was still very much worth reading, like H2G2, I stayed up all night 'til I finished it.
---
script-fu: hash bang slash bin bash
Every interested software developer could release a 'DeCSS' release of anything they release in the next little while.
A DeCSS Linux distro could be formed.
Any other ideas?
---
This machine is obsolete - Trent Reznor, 1999
Personally, I hate package managers. I don't feel comfy with anything other than tar and gzip. The reason is, I need control. Which is why I won't use GUIs unless I have to (i.e. to read slashdot).
/;tar xfz foo.tgz; cd -'. You know where everything is, and you know that you can remove it -by hand- and it won't screw anything up.
.rc files. And I can change root's profile so that rm isn't executed with -i by default (although I don't have to, 'cause I won't use RH).
I'm a slackware user (no holy wars!), and I can live with pkgtool because it's really just a glorified version of 'cd
The only exception I give to this is the CPAN module for perl. The only reason why I'm willing to use it is that I *know* I'll never remove a perl module.
I'll probably get nailed by the user-friendliness advocates. I'm sorry, I don't like macs, GUIs or mice. I think of user-friendliness as idiot-compliancy. It wasn't allways that bad, but seriously, Microsoft et al. have reduced themselves to the lowest common denominator, which is a blundering idiot. I dispise this practice, and I see it happening in the Linux community, which makes me cry. But c'est la vie, besides, I can turn off inetd, rewrite the inittab, and the
Sorry for ranting.
---