Is anybody actually surprised that you can connect a hard drive to a Mac Mini?
Or am I too jaded? Is the great feat here that somebody managed to open a computer case?
Or does the Mac Mini contain salvaged Area 51 technology which shoots lasers when exposed, and did he develop a force field generator to be able to safely locate the ATA connector?
Or did his wife expressly forbid him from buying the Mac Mini, and has he frozen his wife inside a time bubble while devising a way to hide the Mac Mini?
It's just a computer. I don't see what's so interesting about connecting a hard drive to a computer. Open box, connect hard drive, close box. You can't even get the connectors wrong nowadays. Even a monkey could do it. Well, I suppose if a monkey actually did it that would be kind of cool.
No. People should stop approaching UI with the idea that it's just a bit of windowdressing that you can (or should be able to) change and mould any which way you please. It's not true. At least, not without incurring significant costs.
Some examples of these costs include poor integration with the rest of the system (if every app on the system puts the "OK" button on the right side of a dialog, you can't put it left), lowest common denominator design (your UI would benefit greatly from using FancyWidget, but FancyWidget is only available on platform X), poor design (your app is riddled with preferences for what mouse button does what, since every window manager implements different standard behaviors for different mouse buttons; labels and buttons always seem to be a pixel or so off), high development lead time (since to get rid of problems kind you first need to spend time writing a ButtonAlignment class, and to avoid problems of the second kind it needs to be damned flexible), slower application performance (since your ButtonAlignment class adds yet another layer), and high testing costs (since you need to test all possible configurations of your app in all possible environments).
Technology which aims to decouple look and behaviour from the actual code makes it easier to change trivial properties such as colors, fonts, and even layout, but doesn't solve the interesting problem of how to prevent the costs I mentioned above.
Some of these issues are so subtle and insidious that I've grown even to regard superficial theming as a waste of time that causes more trouble than it's worth.
It's good to make it flexible, it's better to make it good.
It's not really a better idea. That's not to say it's a stupid idea. In fact it seems rather natural. But it's woefully misinformed. Basically what you're underestimating is the amount of effort that goes into creating a UI. Except for things like button layouts and colors/fonts (which you can trivially change today through.rc files,.glade files and theme engines), rewriting the UI of an application like Gimp essentially means rewriting up to 70% of the app.
Your suggestion is akin to saying that car manufacturers should create one or two chassis and just put different bodies on top of them. Well, they do. But it still takes years to get from a design to an actual car.
And of course using simd is better than not using it, but i would rather stay on a "let the compiler vectorize it" level. I mean, doing your inner loop in leet assambler only to NOT know after a long simulation if ther results are real or you just botched some line isnt worth it.
Baseless FUD. Why would a few dozen lines of hand coded assembly suddenly invalidate the results?
This is insane. It's like extending the phone system to also use base-60 (to appease the ancient Babylonians, should they ever return) and Roman numerals (can never be too sure).
Not only does it cause issues like this one, it also makes it impossible to reliably visit websites from one computer to the next, which may have different input methods and/or keyboards. Not to mention that it basically kills the possibility of reliably transcribing URLs.
Sorry, but yours is an utterly kneejerk boilerplate response which has nothing to do with the topic at hand and only serves to establish your credentials as a hard nosed realist who has been there and done it.
Moore's Law has eroded the need for such knowledge
Moore's "law" (which is just an off-the-cuff observation, really) has nothing to do with this. If anything, Moore's law has enabled transistor and space devouring SIMD technology.
It would be like concerning myself on how to design circuits...
No, it's nothing like that at all. Just because you own and know how to use money doesn't mean there is no point to the complex financial reckonings that are made every day at institutions all over the world. You may not need, but you is not under discussion.
Yes some people who write games are still concerne with assembly as are people in embedded markets. But those jobs, situations and skills are niche
By this definition, everything is niche. The whole computing industry becomes "niche". Farming is "niche". The paper industry is "niche". What you're describing is just non-descript white collar administrative work which just happens to involve a computer; bit shuffling, rather than paper shuffling.
Those situations are about the last place you will find anyone caring about something called "assembly language."
Again, completely irrelevant.
The point is that with a few dozen lines of SIMD code (whether in assembly or some high level language) any reasonably competent programmer can achieve four-fold, ten-fold, even twenty-fold speedups on critical path code, from scratch, in as little as a week.
These are amazing results, and people should be encouraged to investigate the possibilities, not be dragged down into this drab netherworld of yours.
The key advantage of GNU/Linux and the BSD's is the unfettered freedom to do with them as you please. This freedom is important only to a small number of people, and immediately useful only to an even smaller number. Those who use GNU/Linux and/or BSD on the desktop because it's "better" are either deluding themselves or they are very particular about their environment. In any case, the demand for such systems on the basis of the freedom they provide alone will always be relatively marginal.
That said, historically open systems have always trumped closed ones. Don't forget that Microsoft's success in the late 80's and 90's is due in large part because their systems (first DOS, then Windows 3.0) were more open than those of the competitors (Atari, Commodore, Tandy, Apple, IBM,...).
It's not like Apple has only just now discovered how to build great products. Apple has always been building great stuff, with the possible exception of the "beleagered" late 90's. The current frenzy around Apple, then, can only be partially explained by the greatness of their current crop of merchandise. Much of their success has to be attributed to fashion and sheer hype, which may evaporate as rapidly as it has come. It may only take one guy in a garage working on something we don't know about yet.
Internationally, Apple is a much less powerful brand than might seem the case from an American vantage point. Service can be abysmal, presence is spotty at best. A friend of mine is now on his 3rd or 4th iBook in about 2 years. Each of them has broken down, whether due to the disk failing, the power supply exploding [figure of speech], or the screen/graphics card going bonkers. Each time it means he has to take the iBook away and wait 2 to 6 weeks for it to come back: no substitute on loan, no brand new replacement, not even so much as a sympathetic nod.
The FOSS desktop has made immense progress over the past few years and continues to improve. Progress may be fitful and slow, and detractors may argue that it won't ever lead to something as polished as Mac OS X or even Windows XP (and I think they're probably right), but these people forget that it was the truly horrible system called DOS which ultimately left all others in the dust.
Not really, because OpenGL doesn't define much in the way of a language representation to talk in. It merely defines a model or world view and a set of operations on that model.
Imagine you are in a foreign country where you don't speak the language, and you want to buy an apple from a fruit merchant. Without a common word for "apple" it's going to be hard to get what you want. You can make your desire clear by pointing at the apple, but that's just because then you've reverted to a different kind of language, namely sign language. The problem here is not that you and the merchant don't share the same world view; you both know about fruit and apples. The problem is that you don't share a common representation of that world view.
So for your suggestion to work, OpenGL would first have to define a common language representation. Then the cards would have to include lots of very fast hardware to translate that representation into commands for the graphics hardware (basically it would mean putting the graphics drivers on the cards themselves).
It's certainly possible. It has been done before: this is how PostScript printers work. But it's a trade-off, since it adds considerable cost and reduces the rate of innovation. Maybe in a few years time.
What makes the Tickle Salon special is that the tickling brush acts as a sensor as well: it can learn your body contours and use those to apply various strokes in whatever manner you find pleasurable. In other words, the software driving the Tickle Salon actually knows what it's tickling.
Notably, the Tickle Salon was conceived as an art project, and builds on a long line of other work by the artistic duo notnot. Most of it touches on themes of growth and emergence. It's really exciting to see the Tickle Salon draw so much attention from outside the art world.
I presume this could be converted into a teledildonic device by adding human control to the machine.
That would basically obliterate the concept. The whole point of the Tickle Salon is to get the human out of the loop -- or, if you prefer, to put some organic sense into machinery.
I am MR MBOTO SHAW, Testamentory Executor of the Will of joe_bruin by appointment and prior arrangements made by the Township of KWANZAA-TOBOGO. After further investigation of his Next of Kin proved fruitless, I come to you in utmost Confidentiality so that the fruits of this old man's labor will not get into the hands of corrupt Township officials. Date: Unknown Place: Slashdot
when me and richard m. stallman (the m stands for 'merryweather', did you know that?) started GNU/hurd back in 1908, we were out to replace the closed-internals of the international business machines (ibm) automatic punch card tabulator, which was at use at the time in the department of the census (where me and rich were summer interns). those machines had a 2mm steel case sealed with canadian metric square screws (wherever you call them, please don't correct me). since nobody had any metric screwdrivers at the time, much less square ones, we had no access to the internal cogs and wheels of the tabulator. we definitely did not want to punch through the casing, because that would void our warranty and service contract, and we would have to contract ibm to build us a second tabulator (which cost nearly 200 american dollars, and took 7 months to assemble).
when it (frequently) broke down, we had to call an ibm machinist to come open the case for us and oil the flywheel or unjam the transverse flying arm on the card-feeder. as you can imagine, this seemed hardly the ideal solution, because usually all it needed was a little bit of work that me and rich could easily perform (even through we were not trained calculating machine operators). long story short, we starting working on the GNU/hurd tabulator. the centerpiece to our system was the pipelined card loader, which could load the next punchcard while the calculating engine was stilll churning on the previous card. we had also designed the system so that you could have dual loading mechanisms, so that one would always be running if the other jammed. rich always insisted that we should publish the blueprints for our machine, so that other people in our tabulation club could also build similar machines, and help us with the design. to me the whole idea sounded a bit bolshevik, but richard seemed intent to follow through with it, and i didn't mind so much. honestly, i didn't believe he would ever be able to publish anything, given that his handwriting was quite terrible (although he was working on a new type of typewriter, the electro-macs so that he would be somewhat more legible).
5 years later, when i was conscripted to join the great war in europe, we had a nearly complete tabulator in hand. we had solved nearly all the problems of page clipping and bending that were present in our earlier builds, and our machine could run at a rate of well over 70 cards per minute (compared to the ibm's 42). however, we never completed the loader fully, and the latest model i saw could only hold 3 cards on the loading queue, making it much less than useful (however promising).
i've lost contact with rich during the war years. i had always assumed he's been killed in action. anyway, i'm glad to see he's still going strong with our GNU/hurd tabulator, and wish him well on it. hopefully it will be done before my great grandkids graduate college.
As opposed to computer languages now, where most modern languages (LISP-family excepted) have context-dependent grammars that are incredibly hard to parse correctly and each language has to have a parser written specially for it.
By this criterion we should replace human languages by XML as well.
Unix geeks typically balk at non-textual files, but I blame it on a fundamental lack of imagination. You can have both! Rich source code can be represented as text -- it's just not convenient to edit it like text.
A format which is as flexible and comprehensive as you describe is not convenient to edit period. The problem is that every tool which wants to edit a small part of it needs to understand (or at least be aware of) all of it.
Want to calculate a line number? Have to parse and render the entire document. Want to generate a diff? Have to parse and render the entire document. Want to translate a string? Have to send the entire document to the translator and wait for it to come back. Want to post a code snippet for discussion? Have to create a new file, paste the code snippet, then upload the file, meaning all discussion gets separated from the code. Unless every browser/mail reader/whatever is changed to understand the format, but this just reiterates the point made above.
This is not to say that it wouldn't have its uses, but they'd be rather specialized, and you'd probably end up with only 1 or 2 programs which can actually fully understand the format, somewhat similar to the current situation with Flash and Squeak.
There are very good reasons why we have the functional decomposition we have today. It makes it easier to work with other people.
But security guards aren't in charge of identity, they are in charge of who get's in to a building.
That's a non-starter, because the guard uses (some token of) identity to determine who gets into the building.
The situation where an unverified piece of plastic provides sufficient proof of identity is comparable to the situation where an account has username "administrator" and an empty password. It's just lousy security.
No matter how cryptic usernames and passwords are, they don't make it impossible for an attacker to impersonate someone else. If a security guard has to be able to identify you personally, impersonation is virtually impossible.
Penetration is of course still possible. You can shoot the guard and/or find ways around him. But these are both different issues. If you take the guard out by force you are certain to invite countermeasures. And if you can evade him, then the system is just as broken as a login service with a buffer overflow. With the crucial difference that by evading the guard you still haven't managed to impersonate someone: you have just bypassed the need for identification.
Absolutely. To fool a login prompt into thinking I am John all I need is John's username and password. To fool a guard into thinking I am John requires drastic plastic surgery.
Wrong. Security is a state. Securing is a proces. Look them up, they're in the dictionary.
Security means that you have procedures and mechanisms to prevent and deal with escalations as they occur.
Security means training your staff never to give out passwords, to use PGP, and to close the door behind them. Security means performing unannounced regular tests to see how well these guidelines are being followed.
Security means knowing when your security has been breached and knowing how to grade the severity of the breach. It means having an escalation protocol in place by which you notify your customers, associates and affiliates. It means testing this protocol every so often and evaluating how it can be improved.
Security is about monitoring and controlling the flow of classified information. Since humans are ultimately the only ones who can distinguish between classified information and unclassified information, this will always be a human job.
This is why security always means there needs to be a person in the loop. It's a lot easier to fool a login prompt than to fool a security guard.
OK, another aggregator which slaps a bunch of tangentially related stuff together with little sense or meaning or rhyme. No context, no insight, no story. Just a bunch of semi-relevant flotsam with about as much vividness as a fake tit. No thanks.
I'm a Free Software guy, because after all has been said and done, the GNU philosophy provides a much more rational answer to the question of "Why use it?" than the Open Source Initiative.
The Open Source Initiative answers that question by saying that Open Source software is better: the programs are better, the development model is better, the support is better. In some cases that's at least subjectively true. Apache really is a best-of-class webserver. gcc really is a very good compiler collection.
But then the examples quickly dry up. Mozilla, supposed to be the posterchild of the OSI movement, was years late, and had to be forked to spawn Firefox to finally deliver something people will actually use. It's a bit better in some respects than Internet Explorer, but not by a large margin. What's more it has been plagued by the exact same problems that open source development was supposed to prevent: it's late, security issues have been kept under wraps (you'll need to copy-paste this link into a new browser window), and it's bloated.
That's not to say that it's bad software. In fact, I think it's pretty good software. But after years of development, broad community support, and generous funding by AOL, the end result turns out to be just slightly better than the most important closed source competitor. It's hardly a compelling argument in favor of the supposed superiority of Open Source.
It's easy to go on in this vein, and mention the whole or partial failures of Open Office, or Helixcode, or XFree86, but that would be merely antagonizing and besides, it doesn't prove anything. In order to debunk the claim that Open Source leads to better software, it's not sufficient to mention open source failures: it's necessary to show closed source success as well.
Well, that's not hard either. There's Apple's spectacular introduction of MacOS X, Microsoft's splendid.NET framework, the continued, and apparently unbreakable, dominance of Adobe and Quark in graphic design. Packages like AutoCad, Maya, Cubase, Reason, Live and Final Cut Pro are not just best-of-class, they practically define the industry. And then there's everybody's favorite, games: in the 6 years since the founding of the OSI, the games industry has grown by more than 100%, all without giving open source so much as a second thought.
Considering all this, it's hard to maintain that Open Source implies better software. And if it doesn't imply that, then why use it, or produce it? After all, isn't the Open Source creed all about doing what works best?
Most Open Source advocates aren't quite ready to admit this to themselves yet. They claim Open Source produces more secure software, and use Windows' extremely poor record in this regard to prove it -- but they ignore the rising number of GNU/Linux exploits and the exemplary security record of closed source MacOS and HP/UX. They claim MS Office is bloated, but ignore the lumbering blimp that is Open Office. The list goes on and on, but I'm quite sure that at this point the few people who are still reading will wonder whether this post goes on forever.
When all is said and done, what remains is the love of programming, the joy of seeing your work being put to good use, and the desire to share it with like-minded souls. Being "better" is important; what's more important is how we can protect our rights to share amidst a climate of overbearing patents and corporate favoritism.
This is what the GPL tries to guarantee, and why Free Software is so different from Open Source.
Dude, did you travel through time from the year 1999 to make this comment? Who'd have thought libertarians still existed!
And a fundamentalist libertarian no less, with zero insight into the actual workings of the state, but a deep ideological yearning for a system rigidly derived from axiomatic principles.
Enjoy your stay here, my friend, but be warned that many things have changed since 1999! And when you get back, please contact my past self and tell him to dump his stock immediately! Thanks!
Slashdot Mirror
Is anybody actually surprised that you can connect a hard drive to a Mac Mini?
Or am I too jaded? Is the great feat here that somebody managed to open a computer case?
Or does the Mac Mini contain salvaged Area 51 technology which shoots lasers when exposed, and did he develop a force field generator to be able to safely locate the ATA connector?
Or did his wife expressly forbid him from buying the Mac Mini, and has he frozen his wife inside a time bubble while devising a way to hide the Mac Mini?
But then how does he unfreeze her?
Can't wait to hear what happens next!
It's just a computer. I don't see what's so interesting about connecting a hard drive to a computer. Open box, connect hard drive, close box. You can't even get the connectors wrong nowadays. Even a monkey could do it. Well, I suppose if a monkey actually did it that would be kind of cool.
No. People should stop approaching UI with the idea that it's just a bit of windowdressing that you can (or should be able to) change and mould any which way you please. It's not true. At least, not without incurring significant costs.
Some examples of these costs include poor integration with the rest of the system (if every app on the system puts the "OK" button on the right side of a dialog, you can't put it left), lowest common denominator design (your UI would benefit greatly from using FancyWidget, but FancyWidget is only available on platform X), poor design (your app is riddled with preferences for what mouse button does what, since every window manager implements different standard behaviors for different mouse buttons; labels and buttons always seem to be a pixel or so off), high development lead time (since to get rid of problems kind you first need to spend time writing a ButtonAlignment class, and to avoid problems of the second kind it needs to be damned flexible), slower application performance (since your ButtonAlignment class adds yet another layer), and high testing costs (since you need to test all possible configurations of your app in all possible environments).
Technology which aims to decouple look and behaviour from the actual code makes it easier to change trivial properties such as colors, fonts, and even layout, but doesn't solve the interesting problem of how to prevent the costs I mentioned above.
Some of these issues are so subtle and insidious that I've grown even to regard superficial theming as a waste of time that causes more trouble than it's worth.
It's good to make it flexible, it's better to make it good.
It's not really a better idea. That's not to say it's a stupid idea. In fact it seems rather natural. But it's woefully misinformed. Basically what you're underestimating is the amount of effort that goes into creating a UI. Except for things like button layouts and colors/fonts (which you can trivially change today through .rc files, .glade files and theme engines), rewriting the UI of an application like Gimp essentially means rewriting up to 70% of the app.
Your suggestion is akin to saying that car manufacturers should create one or two chassis and just put different bodies on top of them. Well, they do. But it still takes years to get from a design to an actual car.
Yes, and ten years from now everybody will have their own steam engine.
Bah. n is usually small.
And of course using simd is better than not using it, but i would rather stay on a "let the compiler vectorize it" level. I mean, doing your inner loop in leet assambler only to NOT know after a long simulation if ther results are real or you just botched some line isnt worth it.
Baseless FUD. Why would a few dozen lines of hand coded assembly suddenly invalidate the results?
This is insane. It's like extending the phone system to also use base-60 (to appease the ancient Babylonians, should they ever return) and Roman numerals (can never be too sure).
Not only does it cause issues like this one, it also makes it impossible to reliably visit websites from one computer to the next, which may have different input methods and/or keyboards. Not to mention that it basically kills the possibility of reliably transcribing URLs.
Domain names should just be ASCII.
Sorry, but yours is an utterly kneejerk boilerplate response which has nothing to do with the topic at hand and only serves to establish your credentials as a hard nosed realist who has been there and done it.
Moore's Law has eroded the need for such knowledge
Moore's "law" (which is just an off-the-cuff observation, really) has nothing to do with this. If anything, Moore's law has enabled transistor and space devouring SIMD technology.
It would be like concerning myself on how to design circuits...
No, it's nothing like that at all. Just because you own and know how to use money doesn't mean there is no point to the complex financial reckonings that are made every day at institutions all over the world. You may not need, but you is not under discussion.
Yes some people who write games are still concerne with assembly as are people in embedded markets. But those jobs, situations and skills are niche
By this definition, everything is niche. The whole computing industry becomes "niche". Farming is "niche". The paper industry is "niche". What you're describing is just non-descript white collar administrative work which just happens to involve a computer; bit shuffling, rather than paper shuffling.
Those situations are about the last place you will find anyone caring about something called "assembly language."
Again, completely irrelevant.
The point is that with a few dozen lines of SIMD code (whether in assembly or some high level language) any reasonably competent programmer can achieve four-fold, ten-fold, even twenty-fold speedups on critical path code, from scratch, in as little as a week.
These are amazing results, and people should be encouraged to investigate the possibilities, not be dragged down into this drab netherworld of yours.
Not really, because OpenGL doesn't define much in the way of a language representation to talk in. It merely defines a model or world view and a set of operations on that model.
Imagine you are in a foreign country where you don't speak the language, and you want to buy an apple from a fruit merchant. Without a common word for "apple" it's going to be hard to get what you want. You can make your desire clear by pointing at the apple, but that's just because then you've reverted to a different kind of language, namely sign language. The problem here is not that you and the merchant don't share the same world view; you both know about fruit and apples. The problem is that you don't share a common representation of that world view.
So for your suggestion to work, OpenGL would first have to define a common language representation. Then the cards would have to include lots of very fast hardware to translate that representation into commands for the graphics hardware (basically it would mean putting the graphics drivers on the cards themselves).
It's certainly possible. It has been done before: this is how PostScript printers work. But it's a trade-off, since it adds considerable cost and reduces the rate of innovation. Maybe in a few years time.
What makes the Tickle Salon special is that the tickling brush acts as a sensor as well: it can learn your body contours and use those to apply various strokes in whatever manner you find pleasurable. In other words, the software driving the Tickle Salon actually knows what it's tickling.
Notably, the Tickle Salon was conceived as an art project, and builds on a long line of other work by the artistic duo notnot. Most of it touches on themes of growth and emergence. It's really exciting to see the Tickle Salon draw so much attention from outside the art world.
I presume this could be converted into a teledildonic device by adding human control to the machine.
That would basically obliterate the concept. The whole point of the Tickle Salon is to get the human out of the loop -- or, if you prefer, to put some organic sense into machinery.
I am MR MBOTO SHAW, Testamentory Executor of the Will of joe_bruin by appointment and prior arrangements made by the Township of KWANZAA-TOBOGO. After further investigation of his Next of Kin proved fruitless, I come to you in utmost Confidentiality so that the fruits of this old man's labor will not get into the hands of corrupt Township officials.
Date: Unknown
Place: Slashdot
when me and richard m. stallman (the m stands for 'merryweather', did
you know that?) started GNU/hurd back in 1908, we were out to replace
the closed-internals of the international business machines (ibm)
automatic punch card tabulator, which was at use at the time in the
department of the census (where me and rich were summer interns).
those machines had a 2mm steel case sealed with canadian metric square
screws (wherever you call them, please don't correct me). since nobody
had any metric screwdrivers at the time, much less square ones, we had
no access to the internal cogs and wheels of the tabulator. we
definitely did not want to punch through the casing, because that
would void our warranty and service contract, and we would have to
contract ibm to build us a second tabulator (which cost nearly 200
american dollars, and took 7 months to assemble).
when it (frequently) broke down, we had to call an ibm machinist to
come open the case for us and oil the flywheel or unjam the transverse
flying arm on the card-feeder. as you can imagine, this seemed hardly
the ideal solution, because usually all it needed was a little bit of
work that me and rich could easily perform (even through we were not
trained calculating machine operators).
long story short, we starting working on the GNU/hurd tabulator. the
centerpiece to our system was the pipelined card loader, which could
load the next punchcard while the calculating engine was stilll
churning on the previous card. we had also designed the system so that
you could have dual loading mechanisms, so that one would always be
running if the other jammed. rich always insisted that we should
publish the blueprints for our machine, so that other people in our
tabulation club could also build similar machines, and help us with
the design. to me the whole idea sounded a bit bolshevik, but richard
seemed intent to follow through with it, and i didn't mind so much.
honestly, i didn't believe he would ever be able to publish anything,
given that his handwriting was quite terrible (although he was working
on a new type of typewriter, the electro-macs so that he would be
somewhat more legible).
5 years later, when i was conscripted to join the great war in europe,
we had a nearly complete tabulator in hand. we had solved nearly all
the problems of page clipping and bending that were present in our
earlier builds, and our machine could run at a rate of well over 70
cards per minute (compared to the ibm's 42). however, we never
completed the loader fully, and the latest model i saw could only hold
3 cards on the loading queue, making it much less than useful (however
promising).
i've lost contact with rich during the war years. i had always assumed
he's been killed in action. anyway, i'm glad to see he's still going
strong with our GNU/hurd tabulator, and wish him well on it. hopefully
it will be done before my great grandkids graduate college.
-- joe_bruin @ slashdot
If you can't hear the difference you might as well send your beloved equipment to Africa.
As opposed to computer languages now, where most modern languages (LISP-family excepted) have context-dependent grammars that are incredibly hard to parse correctly and each language has to have a parser written specially for it.
By this criterion we should replace human languages by XML as well.
Unix geeks typically balk at non-textual files, but I blame it on a fundamental lack of imagination. You can have both! Rich source code can be represented as text -- it's just not convenient to edit it like text.
A format which is as flexible and comprehensive as you describe is not convenient to edit period. The problem is that every tool which wants to edit a small part of it needs to understand (or at least be aware of) all of it.
Want to calculate a line number? Have to parse and render the entire document. Want to generate a diff? Have to parse and render the entire document. Want to translate a string? Have to send the entire document to the translator and wait for it to come back. Want to post a code snippet for discussion? Have to create a new file, paste the code snippet, then upload the file, meaning all discussion gets separated from the code. Unless every browser/mail reader/whatever is changed to understand the format, but this just reiterates the point made above.
This is not to say that it wouldn't have its uses, but they'd be rather specialized, and you'd probably end up with only 1 or 2 programs which can actually fully understand the format, somewhat similar to the current situation with Flash and Squeak.
There are very good reasons why we have the functional decomposition we have today. It makes it easier to work with other people.
But security guards aren't in charge of identity, they are in charge of who get's in to a building.
That's a non-starter, because the guard uses (some token of) identity to determine who gets into the building.
The situation where an unverified piece of plastic provides sufficient proof of identity is comparable to the situation where an account has username "administrator" and an empty password. It's just lousy security.
No matter how cryptic usernames and passwords are, they don't make it impossible for an attacker to impersonate someone else. If a security guard has to be able to identify you personally, impersonation is virtually impossible.
Penetration is of course still possible. You can shoot the guard and/or find ways around him. But these are both different issues. If you take the guard out by force you are certain to invite countermeasures. And if you can evade him, then the system is just as broken as a login service with a buffer overflow. With the crucial difference that by evading the guard you still haven't managed to impersonate someone: you have just bypassed the need for identification.
Absolutely. To fool a login prompt into thinking I am John all I need is John's username and password. To fool a guard into thinking I am John requires drastic plastic surgery.
Wrong. Security is a state. Securing is a proces. Look them up, they're in the dictionary.
Security means that you have procedures and mechanisms to prevent and deal with escalations as they occur.
Security means training your staff never to give out passwords, to use PGP, and to close the door behind them. Security means performing unannounced regular tests to see how well these guidelines are being followed.
Security means knowing when your security has been breached and knowing how to grade the severity of the breach. It means having an escalation protocol in place by which you notify your customers, associates and affiliates. It means testing this protocol every so often and evaluating how it can be improved.
Security is about monitoring and controlling the flow of classified information. Since humans are ultimately the only ones who can distinguish between classified information and unclassified information, this will always be a human job.
This is why security always means there needs to be a person in the loop. It's a lot easier to fool a login prompt than to fool a security guard.
OK, another aggregator which slaps a bunch of tangentially related stuff together with little sense or meaning or rhyme. No context, no insight, no story. Just a bunch of semi-relevant flotsam with about as much vividness as a fake tit. No thanks.
Striking. Barry Deutsch did a funny cartoon on exactly this subject almost two years ago. Is this life imitating art or is it a running gag in the US?
I'm a Free Software guy, because after all has been said and done, the GNU philosophy provides a much more rational answer to the question of "Why use it?" than the Open Source Initiative.
.NET framework, the continued, and apparently unbreakable, dominance of Adobe and Quark in graphic design. Packages like AutoCad, Maya, Cubase, Reason, Live and Final Cut Pro are not just best-of-class, they practically define the industry. And then there's everybody's favorite, games: in the 6 years since the founding of the OSI, the games industry has grown by more than 100%, all without giving open source so much as a second thought.
The Open Source Initiative answers that question by saying that Open Source software is better: the programs are better, the development model is better, the support is better. In some cases that's at least subjectively true. Apache really is a best-of-class webserver. gcc really is a very good compiler collection.
But then the examples quickly dry up. Mozilla, supposed to be the posterchild of the OSI movement, was years late, and had to be forked to spawn Firefox to finally deliver something people will actually use. It's a bit better in some respects than Internet Explorer, but not by a large margin. What's more it has been plagued by the exact same problems that open source development was supposed to prevent: it's late, security issues have been kept under wraps (you'll need to copy-paste this link into a new browser window), and it's bloated.
That's not to say that it's bad software. In fact, I think it's pretty good software. But after years of development, broad community support, and generous funding by AOL, the end result turns out to be just slightly better than the most important closed source competitor. It's hardly a compelling argument in favor of the supposed superiority of Open Source.
It's easy to go on in this vein, and mention the whole or partial failures of Open Office, or Helixcode, or XFree86, but that would be merely antagonizing and besides, it doesn't prove anything. In order to debunk the claim that Open Source leads to better software, it's not sufficient to mention open source failures: it's necessary to show closed source success as well.
Well, that's not hard either. There's Apple's spectacular introduction of MacOS X, Microsoft's splendid
Considering all this, it's hard to maintain that Open Source implies better software. And if it doesn't imply that, then why use it, or produce it? After all, isn't the Open Source creed all about doing what works best?
Most Open Source advocates aren't quite ready to admit this to themselves yet. They claim Open Source produces more secure software, and use Windows' extremely poor record in this regard to prove it -- but they ignore the rising number of GNU/Linux exploits and the exemplary security record of closed source MacOS and HP/UX. They claim MS Office is bloated, but ignore the lumbering blimp that is Open Office. The list goes on and on, but I'm quite sure that at this point the few people who are still reading will wonder whether this post goes on forever.
When all is said and done, what remains is the love of programming, the joy of seeing your work being put to good use, and the desire to share it with like-minded souls. Being "better" is important; what's more important is how we can protect our rights to share amidst a climate of overbearing patents and corporate favoritism.
This is what the GPL tries to guarantee, and why Free Software is so different from Open Source.
I apologize for being a jerk. It was supposed to be funny, I guess.
Preventing dictatorship is the best way to help and care for all children.
But what the hell does this have to do with FreeNet?
Dude, did you travel through time from the year 1999 to make this comment? Who'd have thought libertarians still existed!
And a fundamentalist libertarian no less, with zero insight into the actual workings of the state, but a deep ideological yearning for a system rigidly derived from axiomatic principles.
Enjoy your stay here, my friend, but be warned that many things have changed since 1999! And when you get back, please contact my past self and tell him to dump his stock immediately! Thanks!