You said that not all of the 128-bit checksum can be used. Wouldn't
that mean that some files would have the same checksum, that is the
checksum would not be unique now? I mean, when two files have checksum
which have first 64 bits the same and the second 64 bits different
and I use only the first 64 bits, then I have two files with the
same conflicting checksum, am I right?
Well, yes and no.
Yes, you're right that the 64-bit parts of MD5 digests are not unique,
but so are the full 128-bit digests.
Any n-bit digest, provided it's randomly distributed,
will be the same statistically every 2^n times,
since there are only 2^n different results.
Now it's up to you if you think
281474976710656 (48 bits) different digests is enough for you,
or you need 590295810358705651712 (69 bits) or full MD5
340282366920938463463374607431768211456 (128 bits).
You have to use enough bits to make sure
(well, you never can be sure,
like you can't be sure that you won't win a lottery
1000 times in a row
-- you get the idea)
that two files having the
same digest is practically impossible
(because it's always theoretically possible,
however unlikely).
It depends on the number of files you have.
For n-bit digest and m files there are
2^nm different results and
(2^n)!/(2^n - m)! good results
(i.e. those results without collisions).
So, the probability of not having any collisions is
(2^n)!/(2^nm (2^n - m)!)
but since calculating (2^128)! is not what you want to do
(trust me --
a 1000 teraflop supercomputer would need half a million times
more time than the age of our universe,
provided it would have so much RAM and
could handle so long numbers, which I don't even dare estimating).
You better write this from the command line,
it's a little Perl one-liner I just hacked out of boredom
-- yes, I know, I should take my medicine and get some sleep:
perl -le'($n,$m)=@ARGV; for($w=$z=2**$n,++$_;$m;--$m,--$z){$_*=$z/$w} print'n m
Emacs is released under the GPL.
(...)
The restrictions placed on developers by the GPL make it impossible for a commercial concern to use either of these programs, or components of them, as part of an IDE.
Actually, it has been done --
Energize, a C++ IDE made by Lucid Inc
(it came out something around 1991-1992),
used GNU Emacs as an editor (then forked*
GNU Emacs to Lucid Emacs, which finally became XEmacs).
(*It was,
as far as I know,
the most controversial as well as the most significant
fork in the free software community.
See The Lemacs/FSFmacs Schism by Jamie Zawinski
and
A History of Emacs from the XEmacs Internals Manual
for some informations about Lucid Energize
(and for lots of GNU Emacs vs. Lucid/XEmacs flame wars).
There's also a short explaination on
GNU Emacs FAQ, question 8.6.)
So, the point is that Emacs can be used and
has been used as a text editor in proprietary IDE,
while still being released under the GPL.
It was even being sold for well over $4000 per seat, back then.
That said, I totally agree with
GusherJizmac's point:
"The point is, why don't they use those editors as their basis for their integrated editor? Why re-invent the wheel so many times?"
I, for one, won't touch any IDE with a text editor using which
I'm much less productive than using Emacs,
which is an ideal "IDE" for me --
but then again,
I'm
not a big fan of traditional IDEs, so what do I know
(also, I don't use any proprietary software, so
even if Komodo was in my opinion better than Emacs
(or if it included Emacs for that matter),
I still wouldn't use it, anyway
-- I say it just to make things clear: Komodo
may be great for a proprietary IDE).
OK, back to the topic --
Emacs can be legally used
in proprietary IDEs and I suppose ActiveState could
successfully use Emacs as an editor in Komodo and still be able
to sell it. They didn't do that probably because they thought
their customers would prefer ActiveState's editor
over Emacs -- which I believe is true -- not because it's
legally impossible with the GPL.
Speaking of camera angle, am I the only one
who finds this to be the biggest problem with 3D games?
You effectivly have 2 choices:
first person, which lacks good periphieral vision;
or 3rd person, which gives pretty good periphieral vision, but then makes lining up a jump a real pain, also, if the controls are based on the camera they will often change on you while you are in mid-air, really screwing the jump.
Obviously, what we need is something between
the first person and the third person perspective,
someting like... the second person perspective, maybe?
"Every time I get a new copy of ActiveState's Komodo IDE, I do a review that invariably ends "this would be the perfect IDE for me if I were the sort of person who used IDEs". And every time I get the next release, I get closer to being persuaded I should be using IDEs. With Komodo 2.0, ActiveState is getting very, very close to persuading me - but it's not there yet. Let's see what it got right and got wrong this time. (...)"
Read the whole thing,
it's more objective than
the ActiveState's review.
I personally don't use IDEs at all, like Simon Cozens,
and I find his review much more interesting
from my point of view.
If I am to ever start using IDEs I have to know not if
it's good for an IDE, but if it's good for people who
prefered using Emacs/vi so far.
TAKE BREAKS, PEOPLE!!!!
At the very least, sleep 3 hours out of every twenty four.
What about that sleep pattern to take 20 minutes of sleep every
4 hours? Anyone has any experience with programming marathons using
such a sleep?
I'd consider it a "programming marathon," since
a 20 minutes of sleep is less than half an hour break to eat something.
I'd like to hear any stories, but I personally don't know anybody
who sleeps that way.
i never really found a clear reason on which was better performance-wise, though i suspect the filesystem-based way is. i also found it to be less of a hassle to implement. any intelligent thoughts?
Serving images from the filesystem is always faster than serving them
from a database, since the database is also on the filesystem.
(If you think that the DB could cache the results and therefore be faster,
just serve your most frequently requested images from a filesystem in
RAM (a RAM-disk) -- of course you can't cache more than what would fit
in RAM, no matter if you do it yourself or with the DB.)
Using DB for serving images can make sense when you serve
different images in different cases like banners, where you
want to have simpler CGI scripts
(it's because of convenience, not because of performance).
But using database doesn't have to mean
storing images in a database.
If I found out that serving
some of my images would be easier
(and that means less error prone, better to maintain, etc.)
if I used a database, I would do something like this:
I'd store the digests of my images in the DB
(it could be a binary MD5 for example -- just 16 bytes per image).
Then, when my CGI script gets the digest,
it would use it to find
image on the filesystem.
So, if it gets
9743a66f914cc249efca164485a19c5c it serves/images/97/43/a66f/914cc249efca164485a19c5c.png
(splitting a digest to get different directories depth would
depend on the filesystem and number of images of course,
this is just an example; also one could use less than 128 bits of
the digest if it would be enough to have 96 or 64 (depanding
on the number of images) to have shorter paths).
The.png suffix could be also stored in the database to allow
easy use of few different image formats.
(The DB could store more human-friendly paths instead of
message digests of images, but would need more human interaction
-- it's probably a matter of taste).
This way you still can have a cluster of very simple
statical image serving servers in the future,
while having the benefits of databse.
Also the database traffic is much much lower.
The only difference with your scripts is that you send a redirect
instead of actual content, which is even easier.
The most important benefit, however, is that you can have
statical images, database and CGI frontends split into three
independent machines or even groups of machines, when your traffic
become to high for an all-in-one sollution.
Because with the DB-only BLOB images you better have lots of money
for a database cluster
(and DB-CGI bandwidth of redundant internal traffic).
Using a database-stored images when all you need is easier
searching with SQL queries is in my opinion
just using database as an expensive filesystem.
These binaries would be built on a potato system. Those who wanted this sort of thing could simply add another line to their apt sources file, and accept the small risk.
(...)
Adrian Bunk maintained a repository of several updated packages so that 2.4 series kernels could be used on Potato. But I think it would be nice to have this as an official part of Debian.
There are certainly times when one would want a non-CLI interface even if one were blind - for example, when using programs that are not (and should not) be for the console, such as word processors.
You mean the WYSIWYG
(What You See Is What You Get) word processors?
(I hope it's not some stupid joke.)
"The best output a blind person
using WYSIWYG software can hope for
is getting no output at all"
as the anonymous geek quoted on
BLinux FAQ
has said.
There are typesetting (or "word processing") tools working
perfectly well in any text editor you have.
I personally use
Donald Knuth's
TeX and
Leslie Lamport's
LaTeX
extention because they are more powerful
than any WYSIWYG tool I've ever used (including TeXmacs),
while also giving me
much better looking results.
They're not only more powerful for people with good sight like myself,
they can also be used from any text editor a blind person can use,
like the
Emacspeak
for example.
That's if a blind person ever needs such a tool,
like for writing a book or printed article.
Because using word processors for communication
(like most of people use Microsoft Word these days)
instead of plain text email is stupid at least.
Blind + Linux = BLINUX
"The purpose of BLINUX project
is to improve usability of the LINUX operating system
for the user who is blind"
After searching Google for
blind linux,
I found BLINUX as the first result,
I'm surprised no one has suggested it yet.
There's probably everything one should know trying to set up
a Linux box for blind users.
As for the text mode vs. GUI,
let me quote BLINUX FAQ, emphasis is mine:
5.4 X Window Support
5.4.1 Q: Is anyone working on X-Windows screen reading capability?
A: Yes. Don't hold your breath, though. Much of the X stuff will never work well this way.
There has been some discussion here of the superior possibilities for the new Gnome desktop (see the archives for details). The really important thing to understand, is that you have very little reason to be concerned about the GUI stuff, because of the rich functionality available in text mode.
Also, Brian Selden is working on porting Ultrasonix to Linux. Ultrasonix is a screen access package for X that was originally developed for Sun SPARCstations running Solaris; see http://www.henge.com/~brian/ultralin.html for info.
This is basically what I thought, but I searched the FAQ
to make sure how the most interested people feel about it.
The Linux Terminal Server Project would be a cheap base for your plan - one central high-spec server, with a load of low-spec workstations displaying the served (remote X) terminals.
This is exactly what I wanted to suggest.
It's the best solution, especially in terms of maintainance work
and fault-tolerance.
Make sure to see
this clip (RealPlayer unfortunately) to see how adding new computers
to your lab would look like if you choose the LTSP way.
Take a look at this links:
To get really tricky, you could create a Web site that allows users to upload the text of each EULA, and a distilled summary. (...)
Perhaps by doing this, people who blindly click through these things will be made aware of what the real consequences will be.
And what would it say other than
"As part of the installation process,
Permissioned Media will access your MicroSoft Outlook(r) Contacts list and
send an e-mail to persons on your Contacts list inviting them to download
FriendGreetings or related products."?
It's not that the real consequences aren't obvious,
or there's a cryptic lawyer-speak in the fine print -- no,
they actually say this in the EULA, all in capital letters:
"IF YOU DO NOT WANT US TO ACCESS
YOUR CONTACT LIST AND SEND AN E-MAIL MESSAGE TO PERSONS ON THAT LIST, DO
NOT DOWNLOAD, INSTALL, ACCESS OR USE FRIENDGREETINGS."
Don't get me wrong,
I think your idea is great for some EULAs
-- like the Microsoft
security update slowly preparing the system for mandatory DRM
including some very obfuscated statements, so most of people have
no idea what does it really mean
-- but in this case, it couldn't be more verbose.
The problem with Friend Greetings is
that people who installed it
don't give a damn about EULAs at all.
Those same people couldn't probably care less about your
EULA-distiller, while people who do care wouldn't have any
problem after spending two seconds looking at the ALL-IN-CAPS
part of the EULA.
It's fantastic that there is so much happening in the Linux desktop area at the moment. But a plea to you guys -- can we have some co-ordination and co-operation please?
How you can help:
The most important parts of a Debian subproject aren't mailing lists, web pages, or archive space for packages. The most important part is motivated people who make things happen. You don't need to be an official developer to start making packages and patches. The core Debian Desktop team will ensure that your work is integrated. So here's some things you can do: (...)
Who's involved in Debian Desktop:
First of all, anyone who wants to be! (...)
So, who says you can't cooperate with them?
Remember, your competitioin is Microsoft, they have 95% of the desktop market (or there abouts).
You should be teaming together to fight them, not amongst each other.
The purpose of Debian is not to fight Microsoft.
It's purpose is to make a great operating system.
It's also not a company, so the makret share means nothing
as long as there are enough developers willing to spend their free time
contributing to the project.
There's only one critical file? Hey, just email it to me, I'll keep it on my hard drive. If anyone needs it, just shoot me an email.
OK, I'll send you my HOSTS.TXT file.
But remember to update it every few weeks because
the ARPAnet is growing faster then ever after the
adoption of this new, fancy, so called "TCP/IP" technology.
There it is. There's a business opportunity right there. But Hollywood would rather stop you from doing things that they think is harming sales than take a risk and potentially make more money from you.
It is true that Hollywood would make more money if they used your ideas.
It is even true that sharing music or movies can increase sales.
I have never bought a CD unless:
I have heard some music from this exact CD before
on radio (not likely), on TV (even less likely),
or on a CD borrowed from a friend, a mix copy on tape,
on MP3, Ogg Vorbis or other "pirate" medium
or
I know the artist or composer so well that I'm sure
I will like this CD even if I haven't heard a single track yet.
So, the question is: what are they, stupid?
Why the hell do they want to earn less money with making their
customers pissed off, instead of making more money making their
customers happy, and not wasting money on DRM technology and lobbing?
I don't think they are that stupid.
In fact, I don't think they are stupid at all.
They simply know that they are becoming a parasite between
the artist and her fan.
In the past, the artist who wanted to be popular had to reach
her fans with tapes or CDs
(the music would be played on radio and TV only
after the artist became popular).
It was expensive because every
copy of his music needed a physical medium.
Small artists usually don't even get much money from CD sales.
I personally know some artists who didn't make any
money from their first CDs.
So, why did they agree to publish the CD then?
Because they wanted to be known to people.
When they are known, they can earn lots of money
playing concerts on the tours.
So, how does it look today? Instead of selling CDs in order to
be popular, the artist can as well post MP3s to Kazaa
without any need to involving a record industry at all.
And this is what in my opinion this whole DRM
and war on "piracy" is all about.
This is a serious problem to record companies.
How can they solve it?
When people have computers which can't copy music
(and this is a scenerio Hollywood wants --
mandatory DRM in the long run refusing to play non-DRM content),
than how
can people get the music? Obviously someone has to
have a license to copy -- the record companies.
So how can you get popular being unknown artist?
You can post your MP3s to Kazaa but after paying the
record companies so they could kindly stop blocking your content.
This is, in my opinion, the only reasonable explaination.
They are willing to earn less money than they could now,
but survive even when they are no longer needed.
So this is more money for them in the long run,
much more money. They are not stupid,
they are actually very smart in my opinion.
"Evil genius" is a good term for their ideas.
OT: multi-{headed,keyb} sys (Re:New console layer)
on
Linux 3.0
·
· Score: 2, Interesting
It's so aesthetically annoying to be running a multi-headed system, yet be reserved to only one head when on a tty.
Will it be easily possible
(or maybe it is now, then excuse my ignorance)
to have e.g. a system with 4 monitors, 4 keyboards and 4 mice
to act like a server and 4 diskless terminals, only cheaper?
I suppose it'd be easier to have few text consoles then few X servers,
but I have really no idea.
It would be cool to have graphic cards with mouse and keyboard
sockets in them, but I don't think there's such a thing,
at least I've never found anything like that.
Re:My most anticipated feature
on
Linux 3.0
·
· Score: 1
Stupid mistakes in Linux results in a kernel panic with the output sent to the syslog (9 times out of 10 bad code doesn't kill the entire Kernel, so no waiting on the machine to restart), so I definately think that Linux has the upper hand as far as handling poor kernel space code.
You may like developing the
GNU Hurd
drivers then,
which are basically a user-space programs, so they're as easy to debug
as any other applications, and they won't crash the whole system.
Of course it may not make much economical sense for your company to
actually develop Hurd drivers for every piece of hardware you make
(but would be nice of course), maybe just not yet, but you may
be interested from the technical standpoint.
It's a driver developer nirvana, in my opinion.
Check out this papers:
Towards a New Strategy of OS Design by Thomas Bushnell and
The Hurd Hacking Guide by Wolfgang Jährling.
I was compiling a program once (I sure as hell wish I remembered which program it was) and it told me that my refrigerator did not have enough beer.
I love to read Larry Wall's jokes and other comments
hidden in the quickly flashing messages
while I'm building perl.
And I've only used the stable release,
I suppose the development release has more of them.
Get the
perl source
and check it out.
The biggest obstacle to eliminating the mouse in GUI land isn't the WM anymore. Metacity finally fixes the keyboard bindings for moving/resizing windows like -- [ahem] -- that other OS has had since 3.11.
What's the biggest obstacle then? The apps. Tell me, in Mozilla, how do you navigate a web page*? How, in Gimp, do you select a rectangular region?
Hell, using Gimp without a mouse
I can't even draw a horse which doesn't look like
a damn dog on steroids!
Well, I maybe could draw one,
but at least not as fast as I could with a mouse.
The only excuses for not learning the command line are laziness or (misplaced) intimidation. Anyone willing to put forth a miniscule amount of effort can learn enough command line to accomplish certain tasks faster than with a GUI.
I would say that most of people I know who don't learn how to use
command line interface refuse to learn it strictly because of laziness,
while they should learn it because of Laziness,
if you know what I mean.
If it's GPL'd, the above isn't possible. However, it's also much more difficult to incorporate unhacked VP3 support into their players and encoders, because they have to write their own code rather than just using the available library.
What about the
LGPL,
The GNU Lesser General Public License?
I'm not trolling, I would really like to know the disadvantages of releasing Ogg libraries under the LGPL.
I thought that the LGPL would be ideal for such things like Ogg Vorbis and other Ogg libs (like it is for SDL which is used by lots of proprietary projects, for example) and I'm curious why BSD/X11 type licence was chosen over the LGPL.
I've often heard of Cold Fusion that it makes the easy incredibly easy and makes the difficult impossible.
Makes the difficult impossible? That sounds like a bug, not a feature..
Yeah, it's kind of a different linguistic optimization
than e.g. the Perl's one, which
makes easy things easy and hard things possible.
For me it's also a disadvantage, but I guess
that's a matter of taste.
All you need to do is write a script which picks an image and then run a program to transmit it over the network to the display every few seconds. Things like weather, news or mail.
—
Or porn!
Sorry, did I say it out loud?
There was a petition out where you could sign up for demanding a Linux version of the upcoming patch, and I'm sure this has been one of the reasons why they will support it.
There are lots of
Porting Petitions on
Tux Games website:
"Tux Games is determined to see all of the major commercial games ported to Linux. But before this can happen, the major game companies must be made aware of the demand. That is where we come in."
Run a cron job to randomly block the entire yahoo domain, so that the users know that yahoo chat works "some" of the time, but not all. Just like windows, in fact. The usage will drop accordingly.
Good idea, and while you're at it,
you can track those who use Yahoo and
insert purgatives into their coffee,
while inserting D-Lysergic Acid Diethylamide
into coffee of people who didn't use Yahoo in a given day.
When the users will find a subconcious correlation with
their usage of Yahoo and their happiness,
the usage will drop accordingly.
This is what we, network administrators, call
“conditioning.”
Slashdot Mirror
Well, yes and no. Yes, you're right that the 64-bit parts of MD5 digests are not unique, but so are the full 128-bit digests. Any n-bit digest, provided it's randomly distributed, will be the same statistically every 2^n times, since there are only 2^n different results. Now it's up to you if you think 281474976710656 (48 bits) different digests is enough for you, or you need 590295810358705651712 (69 bits) or full MD5 340282366920938463463374607431768211456 (128 bits).
You have to use enough bits to make sure (well, you never can be sure, like you can't be sure that you won't win a lottery 1000 times in a row -- you get the idea) that two files having the same digest is practically impossible (because it's always theoretically possible, however unlikely). It depends on the number of files you have. For n-bit digest and m files there are 2^nm different results and (2^n)!/(2^n - m)! good results (i.e. those results without collisions).
So, the probability of not having any collisions is (2^n)!/(2^nm (2^n - m)!) but since calculating (2^128)! is not what you want to do (trust me -- a 1000 teraflop supercomputer would need half a million times more time than the age of our universe, provided it would have so much RAM and could handle so long numbers, which I don't even dare estimating). You better write this from the command line, it's a little Perl one-liner I just hacked out of boredom -- yes, I know, I should take my medicine and get some sleep:
perl -le'($n,$m)=@ARGV; for($w=$z=2**$n,++$_;$m;--$m,--$z){$_*=$z/$w} print' n m
It will compute (2^n)!/(2^nm (2^n - m)!) (rounded to your floating point resolution) i.e. it will give you the probability of not having any collisions using n-bit digests with m files (-0 means it's impossible and 1 means it's sure or so possible that almost sure). If anyone asks how does it work -- it's magic. Copyright © 2002 alfaiomega. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. There is NO warranty; not even for MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE or READABILITY.
Great, I thought no one would read my comment with Score:1. That's good to hear that someone liked it more than the moderators.
Actually, it has been done -- Energize, a C++ IDE made by Lucid Inc (it came out something around 1991-1992), used GNU Emacs as an editor (then forked* GNU Emacs to Lucid Emacs, which finally became XEmacs).
(*It was, as far as I know, the most controversial as well as the most significant fork in the free software community. See The Lemacs/FSFmacs Schism by Jamie Zawinski and A History of Emacs from the XEmacs Internals Manual for some informations about Lucid Energize (and for lots of GNU Emacs vs. Lucid/XEmacs flame wars). There's also a short explaination on GNU Emacs FAQ, question 8.6.)
So, the point is that Emacs can be used and has been used as a text editor in proprietary IDE, while still being released under the GPL. It was even being sold for well over $4000 per seat, back then.
That said, I totally agree with GusherJizmac's point: "The point is, why don't they use those editors as their basis for their integrated editor? Why re-invent the wheel so many times?" I, for one, won't touch any IDE with a text editor using which I'm much less productive than using Emacs, which is an ideal "IDE" for me -- but then again, I'm not a big fan of traditional IDEs, so what do I know (also, I don't use any proprietary software, so even if Komodo was in my opinion better than Emacs (or if it included Emacs for that matter), I still wouldn't use it, anyway -- I say it just to make things clear: Komodo may be great for a proprietary IDE).
OK, back to the topic -- Emacs can be legally used in proprietary IDEs and I suppose ActiveState could successfully use Emacs as an editor in Komodo and still be able to sell it. They didn't do that probably because they thought their customers would prefer ActiveState's editor over Emacs -- which I believe is true -- not because it's legally impossible with the GPL.
Obviously, what we need is something between the first person and the third person perspective, someting like... the second person perspective, maybe?
There's a Review of Komodo 2.0 (printer/human friendly version) by Simon Cozens on Perl.com from October 09, 2002:
Read the whole thing, it's more objective than the ActiveState's review. I personally don't use IDEs at all, like Simon Cozens, and I find his review much more interesting from my point of view. If I am to ever start using IDEs I have to know not if it's good for an IDE, but if it's good for people who prefered using Emacs/vi so far.
What about that sleep pattern to take 20 minutes of sleep every 4 hours? Anyone has any experience with programming marathons using such a sleep? I'd consider it a "programming marathon," since a 20 minutes of sleep is less than half an hour break to eat something. I'd like to hear any stories, but I personally don't know anybody who sleeps that way.
Serving images from the filesystem is always faster than serving them from a database, since the database is also on the filesystem. (If you think that the DB could cache the results and therefore be faster, just serve your most frequently requested images from a filesystem in RAM (a RAM-disk) -- of course you can't cache more than what would fit in RAM, no matter if you do it yourself or with the DB.)
Using DB for serving images can make sense when you serve different images in different cases like banners, where you want to have simpler CGI scripts (it's because of convenience, not because of performance). But using database doesn't have to mean storing images in a database.
If I found out that serving some of my images would be easier (and that means less error prone, better to maintain, etc.) if I used a database, I would do something like this: I'd store the digests of my images in the DB (it could be a binary MD5 for example -- just 16 bytes per image). Then, when my CGI script gets the digest, it would use it to find image on the filesystem.
So, if it gets 9743a66f914cc249efca164485a19c5c it serves /images/97/43/a66f/914cc249efca164485a19c5c.png
(splitting a digest to get different directories depth would
depend on the filesystem and number of images of course,
this is just an example; also one could use less than 128 bits of
the digest if it would be enough to have 96 or 64 (depanding
on the number of images) to have shorter paths).
The .png suffix could be also stored in the database to allow
easy use of few different image formats.
(The DB could store more human-friendly paths instead of message digests of images, but would need more human interaction -- it's probably a matter of taste).
This way you still can have a cluster of very simple statical image serving servers in the future, while having the benefits of databse. Also the database traffic is much much lower. The only difference with your scripts is that you send a redirect instead of actual content, which is even easier.
The most important benefit, however, is that you can have statical images, database and CGI frontends split into three independent machines or even groups of machines, when your traffic become to high for an all-in-one sollution. Because with the DB-only BLOB images you better have lots of money for a database cluster (and DB-CGI bandwidth of redundant internal traffic). Using a database-stored images when all you need is easier searching with SQL queries is in my opinion just using database as an expensive filesystem.
Since the current stable release is Debian 3.0 Woody, I'd suggest you apt-get dist-upgrade.
You mean the WYSIWYG (What You See Is What You Get) word processors? (I hope it's not some stupid joke.) "The best output a blind person using WYSIWYG software can hope for is getting no output at all" as the anonymous geek quoted on BLinux FAQ has said. There are typesetting (or "word processing") tools working perfectly well in any text editor you have. I personally use Donald Knuth's TeX and Leslie Lamport's LaTeX extention because they are more powerful than any WYSIWYG tool I've ever used (including TeXmacs), while also giving me much better looking results. They're not only more powerful for people with good sight like myself, they can also be used from any text editor a blind person can use, like the Emacspeak for example. That's if a blind person ever needs such a tool, like for writing a book or printed article. Because using word processors for communication (like most of people use Microsoft Word these days) instead of plain text email is stupid at least.
Blind + Linux = BLINUX
"The purpose of BLINUX project is to improve usability of the LINUX operating system for the user who is blind"
After searching Google for blind linux, I found BLINUX as the first result, I'm surprised no one has suggested it yet. There's probably everything one should know trying to set up a Linux box for blind users.
As for the text mode vs. GUI, let me quote BLINUX FAQ, emphasis is mine:
This is basically what I thought, but I searched the FAQ to make sure how the most interested people feel about it.
This is exactly what I wanted to suggest. It's the best solution, especially in terms of maintainance work and fault-tolerance. Make sure to see this clip (RealPlayer unfortunately) to see how adding new computers to your lab would look like if you choose the LTSP way. Take a look at this links:
Good luck!
And what would it say other than "As part of the installation process, Permissioned Media will access your MicroSoft Outlook(r) Contacts list and send an e-mail to persons on your Contacts list inviting them to download FriendGreetings or related products."?
It's not that the real consequences aren't obvious, or there's a cryptic lawyer-speak in the fine print -- no, they actually say this in the EULA, all in capital letters: "IF YOU DO NOT WANT US TO ACCESS YOUR CONTACT LIST AND SEND AN E-MAIL MESSAGE TO PERSONS ON THAT LIST, DO NOT DOWNLOAD, INSTALL, ACCESS OR USE FRIENDGREETINGS."
Don't get me wrong, I think your idea is great for some EULAs -- like the Microsoft security update slowly preparing the system for mandatory DRM including some very obfuscated statements, so most of people have no idea what does it really mean -- but in this case, it couldn't be more verbose.
The problem with Friend Greetings is that people who installed it don't give a damn about EULAs at all. Those same people couldn't probably care less about your EULA-distiller, while people who do care wouldn't have any problem after spending two seconds looking at the ALL-IN-CAPS part of the EULA.
Let me quote the article:
So, who says you can't cooperate with them?
The purpose of Debian is not to fight Microsoft. It's purpose is to make a great operating system. It's also not a company, so the makret share means nothing as long as there are enough developers willing to spend their free time contributing to the project.
OK, I'll send you my HOSTS.TXT file. But remember to update it every few weeks because the ARPAnet is growing faster then ever after the adoption of this new, fancy, so called "TCP/IP" technology.
It is true that Hollywood would make more money if they used your ideas. It is even true that sharing music or movies can increase sales. I have never bought a CD unless:
So, the question is: what are they, stupid? Why the hell do they want to earn less money with making their customers pissed off, instead of making more money making their customers happy, and not wasting money on DRM technology and lobbing?
I don't think they are that stupid. In fact, I don't think they are stupid at all. They simply know that they are becoming a parasite between the artist and her fan.
In the past, the artist who wanted to be popular had to reach her fans with tapes or CDs (the music would be played on radio and TV only after the artist became popular). It was expensive because every copy of his music needed a physical medium. Small artists usually don't even get much money from CD sales. I personally know some artists who didn't make any money from their first CDs. So, why did they agree to publish the CD then? Because they wanted to be known to people. When they are known, they can earn lots of money playing concerts on the tours.
So, how does it look today? Instead of selling CDs in order to be popular, the artist can as well post MP3s to Kazaa without any need to involving a record industry at all. And this is what in my opinion this whole DRM and war on "piracy" is all about.
This is a serious problem to record companies. How can they solve it? When people have computers which can't copy music (and this is a scenerio Hollywood wants -- mandatory DRM in the long run refusing to play non-DRM content), than how can people get the music? Obviously someone has to have a license to copy -- the record companies. So how can you get popular being unknown artist? You can post your MP3s to Kazaa but after paying the record companies so they could kindly stop blocking your content.
This is, in my opinion, the only reasonable explaination. They are willing to earn less money than they could now, but survive even when they are no longer needed. So this is more money for them in the long run, much more money. They are not stupid, they are actually very smart in my opinion. "Evil genius" is a good term for their ideas.
Will it be easily possible (or maybe it is now, then excuse my ignorance) to have e.g. a system with 4 monitors, 4 keyboards and 4 mice to act like a server and 4 diskless terminals, only cheaper? I suppose it'd be easier to have few text consoles then few X servers, but I have really no idea. It would be cool to have graphic cards with mouse and keyboard sockets in them, but I don't think there's such a thing, at least I've never found anything like that.
You may like developing the GNU Hurd drivers then, which are basically a user-space programs, so they're as easy to debug as any other applications, and they won't crash the whole system. Of course it may not make much economical sense for your company to actually develop Hurd drivers for every piece of hardware you make (but would be nice of course), maybe just not yet, but you may be interested from the technical standpoint. It's a driver developer nirvana, in my opinion. Check out this papers: Towards a New Strategy of OS Design by Thomas Bushnell and The Hurd Hacking Guide by Wolfgang Jährling.
I love to read Larry Wall's jokes and other comments hidden in the quickly flashing messages while I'm building perl. And I've only used the stable release, I suppose the development release has more of them. Get the perl source and check it out.
Hell, using Gimp without a mouse I can't even draw a horse which doesn't look like a damn dog on steroids! Well, I maybe could draw one, but at least not as fast as I could with a mouse.
I would say that most of people I know who don't learn how to use command line interface refuse to learn it strictly because of laziness, while they should learn it because of Laziness, if you know what I mean.
What about the LGPL, The GNU Lesser General Public License? I'm not trolling, I would really like to know the disadvantages of releasing Ogg libraries under the LGPL. I thought that the LGPL would be ideal for such things like Ogg Vorbis and other Ogg libs (like it is for SDL which is used by lots of proprietary projects, for example) and I'm curious why BSD/X11 type licence was chosen over the LGPL.
Yeah, it's kind of a different linguistic optimization than e.g. the Perl's one, which makes easy things easy and hard things possible. For me it's also a disadvantage, but I guess that's a matter of taste.
All you need to do is write a script which picks an image and then run a program to transmit it over the network to the display every few seconds. Things like weather, news or mail. — Or porn! Sorry, did I say it out loud?
There are lots of Porting Petitions on Tux Games website: "Tux Games is determined to see all of the major commercial games ported to Linux. But before this can happen, the major game companies must be made aware of the demand. That is where we come in."
The only "intuitive" interface is the nipple. After that, it's all learned. — Bruce Ediger
Good idea, and while you're at it, you can track those who use Yahoo and insert purgatives into their coffee, while inserting D-Lysergic Acid Diethylamide into coffee of people who didn't use Yahoo in a given day. When the users will find a subconcious correlation with their usage of Yahoo and their happiness, the usage will drop accordingly. This is what we, network administrators, call “conditioning.”