Nobody uses RSA to encrypt multi-megabyte files anyway. Traditionally you use a public key algorythim to encrypt a session key (realistically no bigger than 32 bytes or so), and then use the session key to encrypt the message with a well known and tested symmetric algorythim (like 3Des, Blowfish, IDEA, etc).
I would be willing to argue that since a compiler is a nessisary part of an operating system that no release of Microsoft Windows actually qualifies as an OS. Unfortunately,
everyone would ignore me.
By that logic, I'm running the "Debian" Operating System right now, and I have the "Red Hat" Operating System on my laptop. Equally valid with your logic would be to use the Vendor's actual product names "Debian GNU/Linux" and "Red Hat Linux".
On the other hand, following your metafor, you could argue that the GNU/Linux situation is more like if the GNU project designed a car with everything but an ignition system, and Linus Torvalds came along, licenced the GNU design and dropped in a "Linux" ignition system. If then a car company called Red Hat came along and actually produced the car, shouldn't they call it Red Hat GNU/Linux?
Unfortunatly, at this point, everyone knows of the operating system as "Linux", and for clarity I will continue refering to it as such.
You can explicitly include language in your contract with the development company that they will not release the code to the outside world, and that the code will remain a trade secret of Spacely Sprockets once it has been developed.
Re:Compiling 2.1 now, worth the upgrade?
on
KDE 2.2 Released
·
· Score: 1
deb http://http.us.debian.org/debian/ unstable main
Re:Compiling 2.1 now, worth the upgrade?
on
KDE 2.2 Released
·
· Score: 1
If you are running Debian, just hook in an "unstable" line in your sources.list - The 2.2final packages in debian unstable have been out for days now.
I've been running Debian unstable on my destkop for months now, and the only thing that can be "Unstable" is package dependancys, and even that is rarely a real issue.
IBM is blantantly ignoring Linux on the desktop. They're only interested in what they can make money selling to their customers *now*, and they've decided that that's Windows on the desktop and Linux on the server.
I haven't had any significant issues with this at all.
All of Loki's 2D games that I've gotten (SMAC, CivCTP, SimCity3k) installed cleanly out of the box with a single "sh setup.sh" command, as described on the quick install CD case insert.
It's been the same for the 3D games (HG2, sof, Decent3), now that I have the 3D drivers for my video card installed.
Even getting the 3D drivers installed wasn't too hard, I just had to download them from http://www.nvidia.com/, tar xzf the tarball, and run "make" as root (just like it said in the installation instructions on the download page).
Realisticly, anyone who has Linux installed to begin with can handle getting 3D games up and running on their systems... at least if they have supported hardware.
The only thing that sucks about Debian is that the software in the latest distro is pretty old but at least it's all proven stability.
Give Debian Unstable a try. It's about as stable as a new release of Red Hat, and it has all kinds of bleeding edge software. You get all the *relitively* stable GUI betas (I seem to have KDE 2.2beta1 installed right now), along with solid, up to date, core software. (I've got the latest stable release of XFree86 4). For a desktop system, the slight loss of stability is worth it (at least to me) for the feature gain.
I just finished writing a Perl program that does password based blowfish file encryption and decryption.
First, it uses Getopt::Long to parse command line options. Then, it uses Term::ReadKey to read
in a passphrase with no terminal echo. It uses Digest::SHA1 to hash the passphrase. Compress::Zlib compresses the data. Crypt::CBC and Crypt::Blowfish encrypt the data. MIME::Base64 translates the data two and from Base64 for easy inclusion in email/etc...
The entire script is less than 100 lines of code. Could you do that in Ruby?
DeCSS is not designed allow copying of DVDs, it is to allow *decryption* of DVDs. This allows for things like viewing the DVD, and taking clips of the DVD for fair use purpoises that are impossible without some sort of decryption device.
The expected decryption device is a standard DVD player, but DeCSS is an equally valid device, just as it is equally valid to use Adobe Acrobat Reader or xpdf to view a PDF file.
A Pentium 150 *would* be plenty, as long as the user didn't want to use any recent software...
Even *playing* an MP3 on a system that slow takes up a significant percentage of the CPU time. The speed is absolutely needed, it just takes a little while for the applications to catch up to the hardware. Real time 3D, Voice Recognition, etc all gets *real easy* when you're working with a 4GHz Clawhammer with an NVidia GEforce 4 and SB Live++
You make a common logical error in your assumptions. Just because netcraft claims there are more DOMAINS running under apache servers does not mean that MANY of them have no dymanic content whatsoever and that the majority of IIS survers do. My field experience shows me that most apache servers run static content for huge virtual hosts with zillions of little bitty domains while IIS typically runs only a few domains or only one but they are much larger and more likely to use dynamic content. Your typical ISP runs Apache because it's the free one that came with the free OS they are running cause they have little money. And, true, it's easier to host zillions of "10 meg limit" static page websites on apache. Businesses typically are running IIS and they have a need for dynamic content and use ASP.
I work at a company that does domain web hosting. We server thousands of domains from our servers, both Solaris/Netscape-Enterprise and NT/IIS. Many of our Unix customers use some sort of dynamic content generation, mostly Perl CGIs, whereas about 2/3 of our NT customers use NT just to get Front Page support, and don't use any Dynamic content.
*My* "Field Experiance" would tend to indicate that the majority of the domains served by IIS servers do not serve dynamic content. Also, a good chunk of IIS dynamic content, perhaps 10%, is Perl CGIs.
So, assuming that what we're measuring is "Most common method for serving server side dynamic content, based on greatest use by domain." then CGI/Perl wins cleanly.
Other measures, such as most pages avalible publicly, or most bytes served, I'm less sure about.
Most widely used dynamic content technology in the world? What world?
According to Netcraft, 62% of web servers are running Apache, and another 6% are running Netscape-Enterprise. Only 21% of web servers are running Microsoft IIS.
ASP is only common on IIS.
Chances are, based on that info, it's unlikely that ASP is the most common dynamic content Generator.
Got it. If I'm running KDE as my desktop
environment, with X-Chat as my IRC client,
I don't see any problems from this. At most,
the colors will be different.
If I decide that I want to ditch X-Chat
for KIRC (I think that's the standard KDE IRC client), it's not going to automatically use
my X-Chat settings, nor it it going to log to.xchat/logs, nor it it going to be X-Chat in
any other way - I'll have switched to another
app. This is a normal, perfectly good way to
have things work.
-- 2.) Greater interconnectivity.
Drag + Drop, Cut + Paste, Keybindings
These things aren't really *needed* for normal
users. I can tell you for a fact that I hardly
ever find trouble in not being able to drag+drop between apps, or need to cut+paste anything but plain text.
Keybindings are really a minor issue. If people care, they'll learn them. I don't care, I never use
them.
-- 3.) Development Compatibility
gtk+ and qt are both GUI toolkits, but are designed with different mindsets. This isn't going to change, nor should it, as both toolkits have significant advantages. (Qt in ease of use for C++ programmers, gtk+ in ease of use for everyone else)
APIs for other things may or may not be compatible between the two desktops. If compatibility makes sense - good. If not - good.
If you are writing a GUI app for Unix, it really doesn't matter which desktop you develop for. If you want to use Qt, write for KDE. If you want to use Gtk+, write for Gnome. If you want to use WxWindows, write for that and compile for Gnome.
Who cares. Eithor is fine. Gnome apps run fine under KDE, and KDE apps run fine under Gnome. There are only a few areas of functionality where intercompatibility can be a problem, and in most of those cases it can just
not work.
I really can't remember the last time I tried to embed a KDE component in a Gnome app and got annoyed that it didn't work. Inter-App drag and drop is the same - I don't need it. Just off the top of my head, I can't even think of a Gnome App that I would want to drag and drop into from a KDE app. Copy and paste annoyed me once, I tried to copy some data from a KDE app, and use Edit->Paste to paste it into a Gnome App. This didn't work, middle clicking immediately pasted the text with no problem.
I have absolutely no problem putting a Konqueror button on my Gnome Panel, or a X-Chat menu option on my IceWM menu. I don't really see actually needing more intercompatibility than that.
All of the real itercompatibility problems are getting solved in any case. By Gnome 2.0, Drag and Drop, Cut and Paste, and Embedding should all use the same protocall in both KDE and Gnome, AFAIK.
This leaves the only real difference between KDE and Gnome to be look and feel. Just use the same theme in both if thos bothers you =P
[ This message posted from Konqueror, Running under IceWM, while listening to music with XMMS, and chatting with X-Chat. ]
Slashdot Mirror
Nobody uses RSA to encrypt multi-megabyte files anyway. Traditionally you use a public key algorythim to encrypt a session key (realistically no bigger than 32 bytes or so), and then use the session key to encrypt the message with a well known and tested symmetric algorythim (like 3Des, Blowfish, IDEA, etc).
When did I say anything about a proprietary licence. If you don't want the code distributed, just don't release it.
I would be willing to argue that since a compiler is a nessisary part of an operating system that no release of Microsoft Windows actually qualifies as an OS. Unfortunately, everyone would ignore me.
By that logic, I'm running the "Debian" Operating System right now, and I have the "Red Hat" Operating System on my laptop. Equally valid with your logic would be to use the Vendor's actual product names "Debian GNU/Linux" and "Red Hat Linux".
On the other hand, following your metafor, you could argue that the GNU/Linux situation is more like if the GNU project designed a car with everything but an ignition system, and Linus Torvalds came along, licenced the GNU design and dropped in a "Linux" ignition system. If then a car company called Red Hat came along and actually produced the car, shouldn't they call it Red Hat GNU/Linux?
Unfortunatly, at this point, everyone knows of the operating system as "Linux", and for clarity I will continue refering to it as such.
You can explicitly include language in your contract with the development company that they will not release the code to the outside world, and that the code will remain a trade secret of Spacely Sprockets once it has been developed.
deb http://http.us.debian.org/debian/ unstable main
apt-get update
apt-get install kdebase
Deltree /y /winnt
Poor, you'd hit his content.
On the other hand, something like:
move \inetpub \inetpub.old
move \winnt \winnt.old
force-reboot
would be perfectly acceptable.
If you are running Debian, just hook in an "unstable" line in your sources.list - The 2.2final packages in debian unstable have been out for days now.
I've been running Debian unstable on my destkop for months now, and the only thing that can be "Unstable" is package dependancys, and even that is rarely a real issue.
IBM is blantantly ignoring Linux on the desktop. They're only interested in what they can make money selling to their customers *now*, and they've decided that that's Windows on the desktop and Linux on the server.
I haven't had any significant issues with this at all.
All of Loki's 2D games that I've gotten (SMAC, CivCTP, SimCity3k) installed cleanly out of the box with a single "sh setup.sh" command, as described on the quick install CD case insert.
It's been the same for the 3D games (HG2, sof, Decent3), now that I have the 3D drivers for my video card installed.
Even getting the 3D drivers installed wasn't too hard, I just had to download them from http://www.nvidia.com/, tar xzf the tarball, and run "make" as root (just like it said in the installation instructions on the download page).
Realisticly, anyone who has Linux installed to begin with can handle getting 3D games up and running on their systems... at least if they have supported hardware.
Give Debian Unstable a try. It's about as stable as a new release of Red Hat, and it has all kinds of bleeding edge software. You get all the *relitively* stable GUI betas (I seem to have KDE 2.2beta1 installed right now), along with solid, up to date, core software. (I've got the latest stable release of XFree86 4). For a desktop system, the slight loss of stability is worth it (at least to me) for the feature gain.
I just finished writing a Perl program that does password based blowfish file encryption and decryption.
First, it uses Getopt::Long to parse command line options. Then, it uses Term::ReadKey to read in a passphrase with no terminal echo. It uses Digest::SHA1 to hash the passphrase. Compress::Zlib compresses the data. Crypt::CBC and Crypt::Blowfish encrypt the data. MIME::Base64 translates the data two and from Base64 for easy inclusion in email/etc...
The entire script is less than 100 lines of code. Could you do that in Ruby?
Your problems with curses are caused by working under Windows with no curses library installed, yes?
Perhaps.... because Oracle isn't an OODBMS.
Ahh... you missed it.
DeCSS is not designed allow copying of DVDs, it is to allow *decryption* of DVDs. This allows for things like viewing the DVD, and taking clips of the DVD for fair use purpoises that are impossible without some sort of decryption device.
The expected decryption device is a standard DVD player, but DeCSS is an equally valid device, just as it is equally valid to use Adobe Acrobat Reader or xpdf to view a PDF file.
A Pentium 150 *would* be plenty, as long as the user didn't want to use any recent software...
Even *playing* an MP3 on a system that slow takes up a significant percentage of the CPU time. The speed is absolutely needed, it just takes a little while for the applications to catch up to the hardware. Real time 3D, Voice Recognition, etc all gets *real easy* when you're working with a 4GHz Clawhammer with an NVidia GEforce 4 and SB Live++
ASCII charactor EOF? What the hell kind of ASCII EOF would be in a binary file?
That's a different problem with a different solution.
I work at a company that does domain web hosting. We server thousands of domains from our servers, both Solaris/Netscape-Enterprise and NT/IIS. Many of our Unix customers use some sort of dynamic content generation, mostly Perl CGIs, whereas about 2/3 of our NT customers use NT just to get Front Page support, and don't use any Dynamic content.
*My* "Field Experiance" would tend to indicate that the majority of the domains served by IIS servers do not serve dynamic content. Also, a good chunk of IIS dynamic content, perhaps 10%, is Perl CGIs.
So, assuming that what we're measuring is "Most common method for serving server side dynamic content, based on greatest use by domain." then CGI/Perl wins cleanly.
Other measures, such as most pages avalible publicly, or most bytes served, I'm less sure about.
Most widely used dynamic content technology in the world? What world?
According to Netcraft, 62% of web servers are running Apache, and another 6% are running Netscape-Enterprise. Only 21% of web servers are running Microsoft IIS.
ASP is only common on IIS.
Chances are, based on that info, it's unlikely that ASP is the most common dynamic content Generator.
Three separate issues.
-- 1.) Play nice together
Got it. If I'm running KDE as my desktop environment, with X-Chat as my IRC client, I don't see any problems from this. At most, the colors will be different.
If I decide that I want to ditch X-Chat for KIRC (I think that's the standard KDE IRC client), it's not going to automatically use my X-Chat settings, nor it it going to log to .xchat/logs, nor it it going to be X-Chat in
any other way - I'll have switched to another
app. This is a normal, perfectly good way to
have things work.
-- 2.) Greater interconnectivity.
Drag + Drop, Cut + Paste, Keybindings
These things aren't really *needed* for normal users. I can tell you for a fact that I hardly ever find trouble in not being able to drag+drop between apps, or need to cut+paste anything but plain text.
Keybindings are really a minor issue. If people care, they'll learn them. I don't care, I never use them.
-- 3.) Development Compatibility
gtk+ and qt are both GUI toolkits, but are designed with different mindsets. This isn't going to change, nor should it, as both toolkits have significant advantages. (Qt in ease of use for C++ programmers, gtk+ in ease of use for everyone else)
APIs for other things may or may not be compatible between the two desktops. If compatibility makes sense - good. If not - good.
If you are writing a GUI app for Unix, it really doesn't matter which desktop you develop for. If you want to use Qt, write for KDE. If you want to use Gtk+, write for Gnome. If you want to use WxWindows, write for that and compile for Gnome.
Only if the game you are playing relies on the numpad, or the INS/HOME/PGUP box layout. You should be able to remap the keyboard to use
QWE
ASD
ZXC
instead of the numpad.
I run Gnome Apps in KDE all the time. They seem to work fine for me.
Who cares. Eithor is fine. Gnome apps run fine under KDE, and KDE apps run fine under Gnome. There are only a few areas of functionality where intercompatibility can be a problem, and in most of those cases it can just not work.
I really can't remember the last time I tried to embed a KDE component in a Gnome app and got annoyed that it didn't work. Inter-App drag and drop is the same - I don't need it. Just off the top of my head, I can't even think of a Gnome App that I would want to drag and drop into from a KDE app. Copy and paste annoyed me once, I tried to copy some data from a KDE app, and use Edit->Paste to paste it into a Gnome App. This didn't work, middle clicking immediately pasted the text with no problem.
I have absolutely no problem putting a Konqueror button on my Gnome Panel, or a X-Chat menu option on my IceWM menu. I don't really see actually needing more intercompatibility than that.
All of the real itercompatibility problems are getting solved in any case. By Gnome 2.0, Drag and Drop, Cut and Paste, and Embedding should all use the same protocall in both KDE and Gnome, AFAIK.
This leaves the only real difference between KDE and Gnome to be look and feel. Just use the same theme in both if thos bothers you =P
[ This message posted from Konqueror, Running under IceWM, while listening to music with XMMS, and chatting with X-Chat. ]