This falls into the catagory of "the analog would is hard to simulate" area of cryptography. These range from the wildly useful (e.g. radioactive decay sensors) to the "whoops, I though it was secure" (e.g. the example in Cryptonomicon of the woman who peeks at the bingo balls and "makes it more random").
Mostly it's a great way to come up with one time pads and otherwise feed random number needs in various crypto applications. Not terribly useful as a means of crypto per se.
I agree to a point. I don't think that you should be allowed to a) do something illegal and then b) sell the movie rights or the photographs or the poetry you wrote while doing it. You should be allowed to talk about it, but not for money. Why? Because it rewards the behavior. Our institutions of reform are pretty awful, but to turn around and give someone money for the crime is even worse.
This extends to exploitation media (be it children, rape, snuff, etc). It should be illegal to sell that media. Should it be illegal to own it? No, I don't think so. It's too easy in this day and age to simply collect all of USENET or download anything from gnutella with an "a" in the name or log every transmission over your corporate gateway. Each of those could be a perfectly legitimate activity which should not be illegal, and yet each of those could also be an attempt to "hide" your true interests (e.g. I might be saving a full USENET spool in order to get access to alt.pictures.naked.lemurs).
So, if what you're doing is swapping 20-year-old kiddie porn on Gnutella, I can't see why I'd throw you in jail.
Now, here's the sticky one: what if you run an ISP that doesn't connect to the Internet at all, but rather runs a private network for its customers who do nothing but trade porn. This one I have no idea how to deal with.
Long term, I think the thing that governments are going to get freaked out by is that we're going to get to the point storage and bandwidth wise wher most people just don't know what's on their hard-drives. Storage media will just become a sort of racial memory. It's not illegal to have seen kiddie porn once in your life, even though that means that it's stored in your memory. What happens when you can put your "memories" up for FTP access? What about the contents of your browser cache that happens to have some pop-up add from a less-than-reputable porn site?
Heh, things will be getting interesting any minute now!
We're talking past each other, so I guess it's time to stop. Suffice to say that if you can write the better content management system, I'll run it....
A few hundred thousand cycles is reasonable for well written code generating a web page from cached data.
Most assuredly nope!
Sure, I too can come up with a home page for peeling paint that I can generate with a six-line C program. But, even moderate complexity would run you aground.
How are you caching data? How are you locking/cleaning/managing/clearing that cache? Your page generation will have to be in bed with that to some extent in order to determine if a new page request invalidates some or all of the cached data that it touches. Then, you're going to have the small matter of how you share this cached data. Is it in a simple database (e.g. Berkeley DB) or a second-tier relational database or do you try to manage a live, shared memory cache. Cache consistency management on that's going to get ugly fast!
Now, you start dealing with protocol management, HEAD vs GET vs POST requests, parsing POST bodies. URL-encoding, cookie access, security, etc, etc.
"Well written code" as defined by number of cycles consumed usually means that many of these needs are handled in a one-off way that does not take into account the mountain of special-cases that makes up what we call the World Wide Web.
Instead I suggest you spend all of that premature optmization energy on writing a good cache management system that can mix and match static HTML cache with dynamically generated pages on the fly. That would benefit everyone, not just one Web page.
Worse, the last time we thought we'd discovered extrasolar planets, it was later demonstrated that they may have simply been darker areas of the star. This time, so-called planetary water is probably just some grad-student who sneezed near the equipment:)
Seriously, I have some very strong doubts about what we can tell about a planet that's further out than, say, Uranus. When we can produce detailed maps of surface of one of the larger chunks of rock out in our solor system's Oort cloud, I'll buy that we can begin to take stock in some of the measurements we're making of objects in nearby systems.
Except that the database entries used are more likely to be reused for other requests -- so if the output could be cached, the database certainly would be.
I'm going to explain why this is wrong, but first let me explain that you're in some very good company in having made this assumption. I and just about everyone I know who've seen a good caching content management system in use have been stunned by the simplicity and correctness of the solution. In the case of Vignette (the one I'm most familliar with), I was also stunned that such slipshod software written in a language that couldn't even do lexical scoping (TCL) was doing this one thing so well:-)
Ok, on to the technical. Yes, you can cache your database in memory (Oracle lets you cache gigs and gigs in RAM), but that buys you a lot less than you would think.
You still have to execute millions upon millions of instructions just to generate the simplest page. When an HTML file is on disk, apache just calls sendfile(2), which copies the file from disk to socket with no userland code in between. Trust me when I say that this is so much more efficient that it's not even worth the comparison.
True, but only in the case of huge files that require no disk access to generate dynamically. Since most dynamic content on the Web requires a database....
C's sendfile can (when possible) perform a DMA transfer from the disk controler to the ethernet controler, which will beat the snot out of any relational database access.
file not found
mod_perl intercept of 404 calls xyz.pl
xyz.pl writes xyz.html (e.g. from database)
Request 2: xyz.html
file exists
sendfile or tux used to fire file to socket
Even C cannot dynamically generate a file as fast as it can be read from disk. Granted, you could write the same plugin in C as you wrote in mod_perl (mod_perl uses the C API for apache after all), but it would be a lot more work, and all you would get is the performance boost on that first page generation, after that they perform the same.
This is the model used by at least one major content management system that uses a language that make Perl look zippy by comparison. They still compete because most page views are found on disk.
Of course, now you get to play the cache management game, but that's the right problem to have when serving lots of content.
Tell you what: I'll check out some 60's South-American psych-pop if you'll check out some 00's Scandinavian black/death metal.
Deal.
Yeah, I know there's a lot of good "underground" music. That same friend of mine I mentioned has a band of his own that I think is very creative (woefully psych just isn't my thing). The problem is that there used to be a decently rewarding career path for the most creative and talented of those underground bands. Today, that career path is locked out by the fact that broadcast music and retail sales are 99+% locked out by large labels and companies like Clearstation.
I guess I was a little too abstract in my post, but I don't think you and I really disagree on this point.
mod_perl provides a means for transparently wrapping CGI programs so that they run continuously instead of starting up (and thus parsing) every time a request requirest them.
However, it's much more than a CGI accelerator. It provides hooks into all of the stages of an apache transation.
As an example of the kind of power this gives you, you can write a Perl plugin for Apache that intercepts 404s, and generates a dynamic page which you then cache to disk for future access (far out-stripping even native C dynamic page generation speeds on subsequent hits). This is just one example. You can write whole content management systems using mod_perl, and in fact many have.
Dark Side of the Moon was a masterpiece album (regardless of taste in music, the craftsmanship of everything in that album was astounding). _That_ is the reason that it was on the charts for so long. In 1988, I bought it and listened for the first time, and it blew me away. I don't _like_ all of the music on it, and some of it took years to become relevant to me, but I'm in awe of the work.
I can say that about _nothing_ today. What artist puts out masterfuly crafted albums of songs that explore the human condition? No, today music labels push music that fits a particular market and is bland enough within that market to keep everyone from thinking too much about who's feeding it to them.
Just do yourself a favor and stop listening.
Go back and buy some strange stuff from the 60s or 70s at a used music store. Find a seller on the net who can get you things from the music scenes in other countries (a friend of mine points out that 1960s south-american psych-pop is awesome stuff).
The world is your musical oyster, grab the horseradish and let it slide!:-)
If you look at what Red Hat has done, it's very clever, and really is aimed at adressing what you just said.
What are the top things that "desktop" users the world-round will want to do?
1. Web Browsing 2. Document editing 3. Email
There are some other things such as calendars, contact management and spreadsheets that are hugely popular, but I think the above three items cover what 99% of the computer-using population does 90% of the time (if we're not counting games).
Those three things (and the things that I've mentioned as "alsos") are all done using the same applications under Red Hat regardless of which desktop system you use.
This has annoyed KDE folks because Red Hat chose the Gnome-friendly apps for this purpose, but to be fair, there wasn't really any choice. Evolution is far-and-away the best groupware suite for Linux/BSD. Mozilla too is hard to beat on anything but speed, and in terms of end-users speed loses to wider compatability with complex Web sites.
Personally, I thank Red Hat for making this hard decision. It's time that the free software desktop world grew up and started to work together instead of trying to play "my feature is bigger than your feature".
There is only one Web standard that is truely universal.
text/plain
My web site is designed for reading:-)
Re:Why _do_ people buy Ximian?
on
Inside Ximian
·
· Score: 3, Interesting
I've often wondered why people bother with ximian.
You seem to already know the answer to your own question. However, I will point out that the question in your subject line is not the same as this one. I "bother with" Ximian. I don't usually purchase it unless I have a specific need for media (which I've done once).
Are the packages it releases any better than the ones released by gnome itself?
Well, for starters, Ximian is more than just Gnome. Most people install Ximian because it's a little bit more "tuned" than the version of Gnome that comes with their OS (or, in the case of Solaris, because their OS does not come with Gnome by default at all). However, Ximian also includes many third-party programs that are not part of Gnome propper (e.g. Evolution, which is a Ximian app, not a Gnome app, and at least under Red Hat the Ximian version of Evolution is far more recent and less buggy than the one that comes with the OS). In the end, you probably won't up the overall package count on your machine by much when you install Ximian, but the quality of the installation will generally improve quite a bit (I know this is true for Debian and Red Hat; feel free to comment for your own OS).
Sure, it has a pretty autoupdate feature, but then so does debian and mandrake, and it can be added to redhat
Yep, it can be added to Red Hat quite easily: install Ximian.
Just what is there to encourage people to pay them money?
Businesses over a certain size cannot afford to use a desktop which is not maintained by someone else. Red Hat's desktop (and those of the other Linux vendors, from what I've seen) is ok, but generally unusable for anyone who isn't a developer. This leaves the choice of Ximian, MacOS or Winderz for most companies. I think we'll see a lot more MacOS going out onto corporate desktops, but Ximian's share will probably increase the most rapidly for the next couple of years (it's easier to tripple a user-base of 1000 than it is to tripple a user base of 100,000).
The really interesting gating factor will be what the big Linux Vendors (especially Red Hat, but also Caldera and SuSE), Sun and HP will do with their desktop offerings. Sun could quickly consume the corporate science market, as there's already a big buy-in there. HP could take quite a bit of government seats, as they have some amazingly well entrenched deals with places like the DoT.
And then there's Red Hat. I see Red Hat eating up the educational niche over the next 5-10 years. There's a lot of software that doesn't exist yet, but these places just can't afford to keep playing ball with MS.
Mozilla does use native widgets insofar as it can, This is possible because XUL is very high-level. Under Linux, for example, I'm using Gtk+ widgets. Under Windows I use MFC widgets. It all looks roughly the same by default, but the tools are the hosts, not Mozilla's.
If enough methane bubbles to the surface to change the climate, that will be the last of your worries. The 200-mile-wide fireball will be your first concern, followed by the little problem of heat disipation.
And a nice visualization at that. For those who see this as a pretty picture... oh well. Large, complex systems are hard to understand. When they're made up of hundreds of files, each contianing hundreds or thousands of lines of code, it's nearly impossible to keep "the big picture" in your head. No, of course you wouldn't go to this as a reference, but I would use it as an introductory tool for new coders or as a visual aid for discussions about architectual issues.
The only problem is that you really want to work with a high-level system that can change this picture dynamically. But, still this is a very nice map. I'm curious about what the diagaming inside of each function is about. I'll have to go look at the project to find out.
A chip is not a system. My laptop is "just a Pentium, a calculator on a chip", but not surprisingly, IBM had to do quite a bit of work to turn it into the A31 IBM Thinkpad from heat management to bus architecture to software integration to external I/O management to... well, there's quite a lot.
Heh... "lock your terminal" is an interesting idea. I've been meaning to get around to re-tooling xscreensaver for a long time so that all of the hacks that display your desktop can be overridden with a flag that you can pass an image to. That way xscreensaver can be turned on in "no, use this image instead" mode.
There are other hack attributes that should be centrally controlable like this, but xscreensaver has always wanted to maintain a very hands-off approach to the hacks.
Slashdot Mirror
This falls into the catagory of "the analog would is hard to simulate" area of cryptography. These range from the wildly useful (e.g. radioactive decay sensors) to the "whoops, I though it was secure" (e.g. the example in Cryptonomicon of the woman who peeks at the bingo balls and "makes it more random").
Mostly it's a great way to come up with one time pads and otherwise feed random number needs in various crypto applications. Not terribly useful as a means of crypto per se.
I agree to a point. I don't think that you should be allowed to a) do something illegal and then b) sell the movie rights or the photographs or the poetry you wrote while doing it. You should be allowed to talk about it, but not for money. Why? Because it rewards the behavior. Our institutions of reform are pretty awful, but to turn around and give someone money for the crime is even worse.
This extends to exploitation media (be it children, rape, snuff, etc). It should be illegal to sell that media. Should it be illegal to own it? No, I don't think so. It's too easy in this day and age to simply collect all of USENET or download anything from gnutella with an "a" in the name or log every transmission over your corporate gateway. Each of those could be a perfectly legitimate activity which should not be illegal, and yet each of those could also be an attempt to "hide" your true interests (e.g. I might be saving a full USENET spool in order to get access to alt.pictures.naked.lemurs).
So, if what you're doing is swapping 20-year-old kiddie porn on Gnutella, I can't see why I'd throw you in jail.
Now, here's the sticky one: what if you run an ISP that doesn't connect to the Internet at all, but rather runs a private network for its customers who do nothing but trade porn. This one I have no idea how to deal with.
Long term, I think the thing that governments are going to get freaked out by is that we're going to get to the point storage and bandwidth wise wher most people just don't know what's on their hard-drives. Storage media will just become a sort of racial memory. It's not illegal to have seen kiddie porn once in your life, even though that means that it's stored in your memory. What happens when you can put your "memories" up for FTP access? What about the contents of your browser cache that happens to have some pop-up add from a less-than-reputable porn site?
Heh, things will be getting interesting any minute now!
We're talking past each other, so I guess it's time to stop. Suffice to say that if you can write the better content management system, I'll run it....
Only if you write crappy code
Nope
or you have extremely complicated pages.
Nope
A few hundred thousand cycles is reasonable for well written code generating a web page from cached data.
Most assuredly nope!
Sure, I too can come up with a home page for peeling paint that I can generate with a six-line C program. But, even moderate complexity would run you aground.
How are you caching data? How are you locking/cleaning/managing/clearing that cache? Your page generation will have to be in bed with that to some extent in order to determine if a new page request invalidates some or all of the cached data that it touches. Then, you're going to have the small matter of how you share this cached data. Is it in a simple database (e.g. Berkeley DB) or a second-tier relational database or do you try to manage a live, shared memory cache. Cache consistency management on that's going to get ugly fast!
Now, you start dealing with protocol management, HEAD vs GET vs POST requests, parsing POST bodies. URL-encoding, cookie access, security, etc, etc.
"Well written code" as defined by number of cycles consumed usually means that many of these needs are handled in a one-off way that does not take into account the mountain of special-cases that makes up what we call the World Wide Web.
Instead I suggest you spend all of that premature optmization energy on writing a good cache management system that can mix and match static HTML cache with dynamically generated pages on the fly. That would benefit everyone, not just one Web page.
Worse, the last time we thought we'd discovered extrasolar planets, it was later demonstrated that they may have simply been darker areas of the star. This time, so-called planetary water is probably just some grad-student who sneezed near the equipment :)
Seriously, I have some very strong doubts about what we can tell about a planet that's further out than, say, Uranus. When we can produce detailed maps of surface of one of the larger chunks of rock out in our solor system's Oort cloud, I'll buy that we can begin to take stock in some of the measurements we're making of objects in nearby systems.
Except that the database entries used are more likely to be reused for other requests -- so if the output could be cached, the database certainly would be.
:-)
I'm going to explain why this is wrong, but first let me explain that you're in some very good company in having made this assumption. I and just about everyone I know who've seen a good caching content management system in use have been stunned by the simplicity and correctness of the solution. In the case of Vignette (the one I'm most familliar with), I was also stunned that such slipshod software written in a language that couldn't even do lexical scoping (TCL) was doing this one thing so well
Ok, on to the technical. Yes, you can cache your database in memory (Oracle lets you cache gigs and gigs in RAM), but that buys you a lot less than you would think.
You still have to execute millions upon millions of instructions just to generate the simplest page. When an HTML file is on disk, apache just calls sendfile(2), which copies the file from disk to socket with no userland code in between. Trust me when I say that this is so much more efficient that it's not even worth the comparison.
True, but only in the case of huge files that require no disk access to generate dynamically. Since most dynamic content on the Web requires a database....
C's sendfile can (when possible) perform a DMA transfer from the disk controler to the ethernet controler, which will beat the snot out of any relational database access.
Request 1: xyz.html
file not found
mod_perl intercept of 404 calls xyz.pl
xyz.pl writes xyz.html (e.g. from database)
Request 2: xyz.html
file exists
sendfile or tux used to fire file to socket
Even C cannot dynamically generate a file as fast as it can be read from disk. Granted, you could write the same plugin in C as you wrote in mod_perl (mod_perl uses the C API for apache after all), but it would be a lot more work, and all you would get is the performance boost on that first page generation, after that they perform the same.
This is the model used by at least one major content management system that uses a language that make Perl look zippy by comparison. They still compete because most page views are found on disk.
Of course, now you get to play the cache management game, but that's the right problem to have when serving lots of content.
Tell you what: I'll check out some 60's South-American psych-pop if you'll check out some 00's Scandinavian black/death metal.
Deal.
Yeah, I know there's a lot of good "underground" music. That same friend of mine I mentioned has a band of his own that I think is very creative (woefully psych just isn't my thing). The problem is that there used to be a decently rewarding career path for the most creative and talented of those underground bands. Today, that career path is locked out by the fact that broadcast music and retail sales are 99+% locked out by large labels and companies like Clearstation.
I guess I was a little too abstract in my post, but I don't think you and I really disagree on this point.
mod_perl provides a means for transparently wrapping CGI programs so that they run continuously instead of starting up (and thus parsing) every time a request requirest them.
However, it's much more than a CGI accelerator. It provides hooks into all of the stages of an apache transation.
As an example of the kind of power this gives you, you can write a Perl plugin for Apache that intercepts 404s, and generates a dynamic page which you then cache to disk for future access (far out-stripping even native C dynamic page generation speeds on subsequent hits). This is just one example. You can write whole content management systems using mod_perl, and in fact many have.
Dark Side of the Moon was a masterpiece album (regardless of taste in music, the craftsmanship of everything in that album was astounding). _That_ is the reason that it was on the charts for so long. In 1988, I bought it and listened for the first time, and it blew me away. I don't _like_ all of the music on it, and some of it took years to become relevant to me, but I'm in awe of the work.
:-)
I can say that about _nothing_ today. What artist puts out masterfuly crafted albums of songs that explore the human condition? No, today music labels push music that fits a particular market and is bland enough within that market to keep everyone from thinking too much about who's feeding it to them.
Just do yourself a favor and stop listening.
Go back and buy some strange stuff from the 60s or 70s at a used music store. Find a seller on the net who can get you things from the music scenes in other countries (a friend of mine points out that 1960s south-american psych-pop is awesome stuff).
The world is your musical oyster, grab the horseradish and let it slide!
If you look at what Red Hat has done, it's very clever, and really is aimed at adressing what you just said.
What are the top things that "desktop" users the world-round will want to do?
1. Web Browsing
2. Document editing
3. Email
There are some other things such as calendars, contact management and spreadsheets that are hugely popular, but I think the above three items cover what 99% of the computer-using population does 90% of the time (if we're not counting games).
Those three things (and the things that I've mentioned as "alsos") are all done using the same applications under Red Hat regardless of which desktop system you use.
This has annoyed KDE folks because Red Hat chose the Gnome-friendly apps for this purpose, but to be fair, there wasn't really any choice. Evolution is far-and-away the best groupware suite for Linux/BSD. Mozilla too is hard to beat on anything but speed, and in terms of end-users speed loses to wider compatability with complex Web sites.
Personally, I thank Red Hat for making this hard decision. It's time that the free software desktop world grew up and started to work together instead of trying to play "my feature is bigger than your feature".
Here's some other tidbits from the site:
- a review of the original pilot for Firefly that won't air on Fox until December (apparently it didn't have enough action for Fox).
- Hoshi's almost-bare-breasted scene in Enterprise
- Neil Gaiman writing for Robert Zemeckis
Among many other interesting stories. The only problem is their "talkback" system will make you long for Slash or PHPNukeRedhat has an irritating policy of backporting fixes into previously released versions of each package.
Debian and FreeBSD among many others do the same thing.
No... NO! I can't get my brain around it! Microsoft broke text?! That's it, I'm switching counting numbers with piles of rocks.
;-)
Um... Microsoft hasn't managed to cause counting piles of rocks to cause some horrid security and privacy violation yet, have they?
My web site is designed for reading
I've often wondered why people bother with ximian.
You seem to already know the answer to your own question. However, I will point out that the question in your subject line is not the same as this one. I "bother with" Ximian. I don't usually purchase it unless I have a specific need for media (which I've done once).
Are the packages it releases any better than the ones released by gnome itself?
Well, for starters, Ximian is more than just Gnome. Most people install Ximian because it's a little bit more "tuned" than the version of Gnome that comes with their OS (or, in the case of Solaris, because their OS does not come with Gnome by default at all). However, Ximian also includes many third-party programs that are not part of Gnome propper (e.g. Evolution, which is a Ximian app, not a Gnome app, and at least under Red Hat the Ximian version of Evolution is far more recent and less buggy than the one that comes with the OS). In the end, you probably won't up the overall package count on your machine by much when you install Ximian, but the quality of the installation will generally improve quite a bit (I know this is true for Debian and Red Hat; feel free to comment for your own OS).
Sure, it has a pretty autoupdate feature, but then so does debian and mandrake, and it can be added to redhat
Yep, it can be added to Red Hat quite easily: install Ximian.
Just what is there to encourage people to pay them money?
Businesses over a certain size cannot afford to use a desktop which is not maintained by someone else. Red Hat's desktop (and those of the other Linux vendors, from what I've seen) is ok, but generally unusable for anyone who isn't a developer. This leaves the choice of Ximian, MacOS or Winderz for most companies. I think we'll see a lot more MacOS going out onto corporate desktops, but Ximian's share will probably increase the most rapidly for the next couple of years (it's easier to tripple a user-base of 1000 than it is to tripple a user base of 100,000).
The really interesting gating factor will be what the big Linux Vendors (especially Red Hat, but also Caldera and SuSE), Sun and HP will do with their desktop offerings. Sun could quickly consume the corporate science market, as there's already a big buy-in there. HP could take quite a bit of government seats, as they have some amazingly well entrenched deals with places like the DoT.
And then there's Red Hat. I see Red Hat eating up the educational niche over the next 5-10 years. There's a lot of software that doesn't exist yet, but these places just can't afford to keep playing ball with MS.
Mozilla does use native widgets insofar as it can, This is possible because XUL is very high-level. Under Linux, for example, I'm using Gtk+ widgets. Under Windows I use MFC widgets. It all looks roughly the same by default, but the tools are the hosts, not Mozilla's.
If enough methane bubbles to the surface to change the climate, that will be the last of your worries. The 200-mile-wide fireball will be your first concern, followed by the little problem of heat disipation.
Let's leave the eco-buzzwords at home, shall we?
And a nice visualization at that. For those who see this as a pretty picture... oh well. Large, complex systems are hard to understand. When they're made up of hundreds of files, each contianing hundreds or thousands of lines of code, it's nearly impossible to keep "the big picture" in your head. No, of course you wouldn't go to this as a reference, but I would use it as an introductory tool for new coders or as a visual aid for discussions about architectual issues.
The only problem is that you really want to work with a high-level system that can change this picture dynamically. But, still this is a very nice map. I'm curious about what the diagaming inside of each function is about. I'll have to go look at the project to find out.
There's about 600,000 instances of prior art :-)
As much as I despise Linux "advocates" these days
Why is an advocate a bad thing? I advocate a great many technologies when I feel they are the right tool for the job. Have I done something to offend?
Cool. I must have missed this in the config file. I'll go back and look.
A chip is not a system. My laptop is "just a Pentium, a calculator on a chip", but not surprisingly, IBM had to do quite a bit of work to turn it into the A31 IBM Thinkpad from heat management to bus architecture to software integration to external I/O management to... well, there's quite a lot.
Heh... "lock your terminal" is an interesting idea. I've been meaning to get around to re-tooling xscreensaver for a long time so that all of the hacks that display your desktop can be overridden with a flag that you can pass an image to. That way xscreensaver can be turned on in "no, use this image instead" mode.
There are other hack attributes that should be centrally controlable like this, but xscreensaver has always wanted to maintain a very hands-off approach to the hacks.