OpenVPN will copy from userland to kernel and back to perform its task. As a result it has a speed limit per client which cannot be worked around. It is a fundamental limitation and is around 5MBit per client (multiple clients bandwidth grows as a log of the number to a total of around 15-20MBit). For a distributed installation or road warriors this may prove to your advantage, because no single client can eat all the resources. There is always some resource to go around. If you want higher speeds on a single encrypted point to point link you are better off with IPSEC transport mode overlay of IP-in-IP or IPSEC overlay of PPTP.
While you are correct that OpenVPN is a userland application, and doesn't run in kernel mode, and that can have performance implications, you are way off on your fundamental limitation.
A co-worker and I have personally tested throughput over an OpenVPN connection on a Gigabit ethernet network and observed speeds over 40 MBit/sec. Yes, this was very beefy hardware, and across an otherwise unutilized network segment. . . but this is rather significantly greater than 5Mbit per client.
Heck, what cipher you pick can have a much greater impact on throughput than whether you go with IPSec or OpenVPN. I guarantee that IPSec with 3DES is going to be slower than OpenVPN with blowfish.
Also. . . 5Mbit per client. . . for a VPN. . . and this is supposed to be a major limitation? If someone has a need for greater traffic point-to-point than 5Mbit, they're probably going to end up with a leased line solution anyway. 5Mbit/sec is not chump bandwidth.
OpenVPN operates very much in a Client-Server style, similar to many commercial VPN Concentrators. The server has a fixed IP address, and the clients connect to the server. After authenticating and establishing a connection, the server gives the client a DHCP-style assigned VPN IP address. Any communication done through the VPN is done between that IP and a tunnel-specific IP on the OpenVPN Server.
If you have fixed Peer-to-Peer tunnels, IPSec is the standard, and it works quite well. However, for ease of use, ease of deployment, ease of setup, and cases where you have dynamic clients accessing a single remote network, you really can't beat OpenVPN.
Did you use the OpenVPN provided scripts for managing the keys?
Because I managed to setup a new OpenVPN server from scratch, using certificates for authentication, in less than an hour this afternoon. Admittedly, I've used OpenVPN quite a bit in the past, but I did this setup from scratch, using the provided scripts, and it was *really* easy. Everything "just worked".
Additionally, OpenVPN also supports making use of PAM for authentication, giving you lots of other options. You can even setup OpenVPN to authenticate via RADIUS to an RSA Authentication Manager Server, using RSA SecurID keyfobs. It's pretty slick.;-)
As far as OpenVPN you are deeply mistaken. It has nothing to do with IPSEC. It uses TLS over TCP or TLS over UDP. The second case requires some sequencing. None of the packet formats has anything to do with the IPSEC RFCs, the OS level abstractions have nothing to do with the RFCs and the keying is not anywhere near the madness specified in the IKE RFC.
"OpenVPN uses an industrial-strength security model designed to protect against both passive and active attacks. OpenVPN's security model is based on using SSL/TLS for session authentication and the IPSec ESP protocol for secure tunnel transport over UDP." -- http://openvpn.net/
IPSec's biggest problem is the complexity of the tunnel setup (IKE). The ESP protocol is pretty decent.
The guy suggested a legitimate tool to help the submitter manage their books. There was no demand that it have to be 100% free. The only requirement was that it be easy to use and support an open format. LibraryThing is easy to use, and allows you to export your data as CSV.
It's true that it won't help him "find" his books, but realistically, the only thing that'll help him with that is for him to get off his ass and apply some logical organization. It's as simple as dividing fiction and non-fiction (insert additional major categories as needed), and then arranging them alphabetically within their disciplines.
Realistically, if you design an application from the start with even just a little bit of, well. . . design, and consideration for portability and future growth, database independance is not very difficult.
Unfortunately, it's been my experience that most people don't really think beyond the next few hours when they're coding, which means that making things better later on is a huge chore.
No offense, but your comment is simplistic and silly. You're making unsubstantiated statements that don't really make sense and don't stand up to facts. Did you spend too much money on an Ivy League degree, and now you feel the need to justify the excessive cost?
No offense, but that's both crap, and unrealistic.
I have to manage an Exchange server, and just recently we had a situation where a user was unable to access e-mail in order to set/change their Out of Office reply. The fact that there's no reasonable way for an admin to do that is just stupid. (Yes, there *are* ways to do it, but they are definitely not reasonable).
Also, in the real world, I'd love to see you tell an executive at the company you work for that they don't deserve e-mail because they're too dumb to manage their own Out of Office status. Somehow I don't think you'd be working there much longer if you did.
This is one (of many) places where Exchange fails to perform as it should.
Yes, I find msyelf with a need to count all the rows in a table daily. Sometimes hourly. There's just so many places that I need that information. On the other hand, having the database enforce the consistency of my data. . . who needs that esoteric feature?
There are very good reasons for Postgres being slower at that, and it involves overall improved performance. If you *really* need that information that often (I can't honestly remember the last time I needed it), just set up a counter and a couple of triggers to increment/decrement it. Boom, issue resolved. Now you have your counts, but the rest of us, who don't care about that information, don't have to take the performance hit for it.
As for the dump/restore. . . for a non-trivial application, migrating to a new Database version is a rather large undertaking. Adding a few minutes to include a dump and restore is trivial next to the rest of the upgrade, in my experience.
In the case of Linux, those other people are your support channel. This is one of the many things that makes open source different. In the commercial arena, if I don't like a company's support channel, they aren't going to sell me anything. So if you don't like the users of some open source project, the same sort of decision ought to fall out of that.
Okay, I can understand that. And I think that's a valid argument for a product from a company, or for a smaller open source project.
But when you're talking one of the larger open source projects, or an entire Operating System (Linux), I think the argument falls apart. A single company or small project is likely to have a homogenous support base, and if you don't like it, there aren't a lot of alternatives.
But when you get into a larger project like Linux, that just doesn't apply. There are hundreds of companies offering support, and hundreds of different groups of people who are using it (and can be tapped for support). The variety of different groups of people here is enough that you should be able to find some element that you like.
There are just too many people using something the size of Linux, and it's impossible to generalize about the entire group (although the post I replied to definitely attempted to do just that!).
I can't appreciate it and yes I've used it. An editor that requires that you spend your time bouncing on the meta key fails one of the more important requirements of a text editor - that the editing keys need to be handily placed.
That's a very subjective requirement. Personally, for my own use, I agree with it. That's why I use vi. But the fact that it fails one of your requirements doesn't mean that everyone else will view it the same.
With all due respect to your genius friend there are better programs for editing, reading news and coding. Ever heard of the unix principle of doing one thing and doing it well? Well GNU code usually does more than one thing...and it usually does them all badly. Emacs being a case in point.
There are better programs for you to do those things. He has taken advantage of the strengths of Emacs to customize and enhance it until it is the best program available for him to do those activities.
Regarding the Unix principle and Emacs. . . you really have to blame the Emacs users for that. Emacs started out as a fairly small and lightweight editor. At the begining, it was basically just a very basic editor with a built in lisp interpreter for extensibility. The majority of Emacs functionality has been implemented at a higher level, often by users, via elisp.
I was comparing the system shell of BSD and GNU/Linux. The advantage of sh over bash is not marginal when the system is spawning lots of shells ie. on boot-up. When I ran Linux the system took 3 times as long to come up compared to FreeBSD running the same softs and 2.4 performance wise was abysmal.
Yes, and it still isn't a valid comparison. You're comparing three BSD distributions, which are, despite their kernel level differences (and a few others), very homogenous, with all of the Linux distributions out there, which number in the hundreds, and are often very specialized.
To give one quick example of where it breaks down, I'll point to Debian, my Linux distribution of choice. Debian includes bash, true, but it also includes dash, formerly ash, which is the sh from NetBSD. It is trivial to set/bin/sh to point to dash (in fact, it prompts you with that question upon installation), and *poof*, now the traditional Bourne shell is your system shell.
As far as user shells go, bash is so far behind ksh in function it's not funny. I've already mentioned that bash is shot through with longstanding and seemingly intractable bugs. Which reminds me, the GNU readline library stinks too which is one reason why most developers choose to implement their own.
To each their own. I've tried ksh before, and been forced to use it on multiple occasions, and I didn't particularly care for it. Don't get me wrong, it's better than tcsh, and much better than csh or bourne shell, but it is lacking a number of features that bash supports, and I found it inconvenient and annoying.
I've actually used the GNU readline library before, too. It wasn't my favorite library to develop with, but I've used worse. And it generally gets the job done.
I looked over the hill some 4-5 years ago, saw that to become a GNU developer you have to have the right religious attitude irrespective of whether you can code or not.
That's a steaming pile of horse crap. You can do whatever the hell you want. If you want to sit at home on a Linux machine and develop proprietary software, you're free to do that. No one is gonig to break down your door and beat you with a penguin stick for it.
That was when I dumped GNU/Linux as even then it had become a ghetto for those with some sort of OS religious axe to grind. Now it's beyond a joke (21 kernel vulnerabilities in 3 months!) and the fact that you and others continue to argue that it is good is frankly bizarre.
Ah, so you choose what operating system you use by how much you like other people using it?
Use GNU code for religious reasons but don't use it if you've got work to do or care about using good tools.
The one bit of GNU code that really bugs me: Emacs
I have to admit, I found this to be an odd way of putting things.
Now, you may not be a fan of emacs, but first stating that you shouldn't use GNU code to get things done, and then holding up Emacs as an example, is ignorant at best. I am not personally a fan of Emacs, having discovered vi first, but I still can appreciate the power, flexibility, and usefulness of it.
A friend of mine is big an emacs fan. He uses it for text editing, e-mail, news reading, and coding. He's probably one of the top two or three coders I've ever met in my life. The guy is an absolute wiz. He's easily as productive as two or three normal programmers. And I've seen him do things in Emacs that nearly blows my mind.
You ask what Emacs is? It's probably the most flexible, powerful, and extensible text editor ever created. Although I dislike the implementation, the design theory behind it is beautiful, and has been successfully used by numerous other applications (build a small, fast kernel, or engine, that does implements the core functionality of your program, and build the rest in an extension/scripting language).
Also, a number of your other complaints and comparisons are marginally valid, at best. For example, comparing the Bourne Shell to bash is like comparing the old, original vi, to vim. Both vim and bash are much larger with respect to codebase and resource use, and both likely have more bugs. But they both also offer an immensely great level of functionality. (Although, in fact, both original Bourne shell and original vi have bugs ("features"), which have often been standardized despite their inconsistency.)
If you really want to stay stuck 10+ years in the past, with ancient (but possibly less buggy) software, that's cool. You have that choice.
Me, though. . . I'm looking over that hill there, wondering what we're going to see next.
No, just a very poorly worded title, which seems to be making the rounds.
To sum up the *truth*: Debian isn't dropping support for a bunch of architectures. It's dropping it's requirement that all architectures be synchronized and released as officially stable at the same time.
So in the future, a handful of Debian architectures will be regularly released as "stable", with a synchronized release. The other architectures will be allowed to come up with their own release timetables, based on need and ability.
Personally, I'd rather see them keep Arm as a primary architecture, and move IA64 to SCC. I think Arm will become an increasingly important architecture over the next few years, and I think IA64 will decline further. But, that's something that can be tackled post-sarge.
In a recent interview, one of the higher-ups at Red Hat said they were currently cleaning up the Netscape Directory Server source code in order to make it usable and buildable (he said that it currently required a very complex and involved build environment, and was being simplified).
He said that he expected it to be released within the next few months.
It does 1200x1200 dpi, built in Wifi and Ethernet, supports PCL6 and Postscript 3, 32MB of RAM standard, supports up to 160, sports a 266Mhz PPC CPU, and has built in duplexing.
I picked it up for $350.
According to the printer's status report, I've printed off 17334 pages so far. I've basically had no problems at all. I had it up and running on the LAN within an hour or so, with all of my computers (Linux, Windows, and an old UltraSparc) printing to it beautifuly.
Based on my good experience, a friend of mine picked up the same printer, and he's also raved about it. I don't remember what he paid for it, but I think it was a hair under $400.
If I were buying a new Laser printer, I would buy another one of these in a second. Depending on the features you need, the ML-2550 and ML-2551N may also be good options. The former is identical to the description above, but without the Wifi/Ethernet, the latter is identical except for without the Wifi. The prices for all three tend to fluctuate up and down. The ML-2551N seems to currently be the cheapest, found on PriceGrabber.com for $335 right now.
I know at one point I remember reading that this was being considered, and that Pixar might be involved. I recall that one of the high-up designers at Pixar said that Tron is the reason he got into the business, and that he'd love an opportunity to remake it.
I dunno if that'll happen, but I think there's a good chance it would end up a much better flick if Pixar ran with it. I'd be very curious to see what they could do.
I have all three consoles, too. Plus a Dreamcast. And of course, a PC.
I have 5 XBox games, about 15 PS2 games, about 10 Dreamcast games. ..
And 32 GameCube games.
There are a handful of awesome games on PS2, a couple of great ones for Xbox, and even a few for Dreamcast. But I've got over a dozen games on GameCube that I consider great.
It seems like the ratio of great games to average games is higher on GameCube. Xbox and PS2 are both about the same, but the PS2 has more great games by simple virtue of it having a *lot* more total games available.
I don't know what it is, but I simply seem to find more games that I truly enjoy on GameCube. To each their own, I suppose.
Another thing that people should read carefully is the privacy statement these guys post. There's some interesting stuff in there:
To create an account, we collect your name, email address, and a shipping address. You will also create a password that you may change in the Account page of our site. We use this information to set up your account, to send you a registration confirmation email and to log your shipping information so that we know where to send your order. We may also use your email address to send you information about new services, features, and special offers from us. Members may opt-out of receiving future mailings of this nature by following the relevant instructions articulated in the body of these promotional emails.
Translation: You give us your information. We then sell it to everyone who will pay us for it, and if you want to opt out of it, you'll have to opt out separately for every single one of the hundreds, if not thousands, of companies we sell you to.
We may work with other third party businesses using the personal information that you supply to us on the main signup page to bring selected retail opportunities to our members via direct mail, email and telemarketing. These businesses may include providers of direct marketing services and applications, including lookup and reference, data enhancement, suppression and validation and email marketing.
Translation: We will sell your information to known spammers, provided they pay us for it. We'll also sell it to telemarketers, junk mailers, and data whores who collect this kind of thing so they can resell it.
There is no way to deactivate an account; if you no longer wish to remain a part of a Gratis Internet website, simply stop logging in to your account. Gratis Internet will not share your information.
Translation: Be prepared for a lifetime of spam at a level well above what you're currently experiencing. And since we have it in the fine print, you can't stop us. Heck, we'll keep selling your information to spammers even after you're dead!
If we decide to change our privacy policy, we will post those changes to this privacy statement, the homepage, and other places we deem appropriate so that you are aware of what information we collect, how we use it, and under what circumstances, if any, we disclose it.
We reserve the right to modify this privacy statement at any time, so please review it frequently. If we make material changes to this policy, we will notify you here, by email, or by means of a notice on our web page.
Translation: We'll change our privacy statement whenever we feel like it, and we're not going to tell you about it. And since you can't delete, remove, or even deactivate an account, that means that we can pretty much do anything we want with your information and you'll probably never know about it. Doesn't that sound like fun?
This is really great news. Shadowrun has been one of my absolute favorite RPG's ever since it was released.
Admittedly, the first edition rules were a little rough around the edges, but the stories and setting were all absolutely top notch, and with the second edition rules streamlining a lot of things, I was really impressed.
I would love to see some of the other rulebooks released online, too. Now if I could just find someone to play this with. . . haven't played a table top RPG in years.;-)
Slashdot Mirror
OpenVPN will copy from userland to kernel and back to perform its task. As a result it has a speed limit per client which cannot be worked around. It is a fundamental limitation and is around 5MBit per client (multiple clients bandwidth grows as a log of the number to a total of around 15-20MBit). For a distributed installation or road warriors this may prove to your advantage, because no single client can eat all the resources. There is always some resource to go around. If you want higher speeds on a single encrypted point to point link you are better off with IPSEC transport mode overlay of IP-in-IP or IPSEC overlay of PPTP.
While you are correct that OpenVPN is a userland application, and doesn't run in kernel mode, and that can have performance implications, you are way off on your fundamental limitation.
A co-worker and I have personally tested throughput over an OpenVPN connection on a Gigabit ethernet network and observed speeds over 40 MBit/sec. Yes, this was very beefy hardware, and across an otherwise unutilized network segment. . . but this is rather significantly greater than 5Mbit per client.
Heck, what cipher you pick can have a much greater impact on throughput than whether you go with IPSec or OpenVPN. I guarantee that IPSec with 3DES is going to be slower than OpenVPN with blowfish.
Also. . . 5Mbit per client. . . for a VPN. . . and this is supposed to be a major limitation? If someone has a need for greater traffic point-to-point than 5Mbit, they're probably going to end up with a leased line solution anyway. 5Mbit/sec is not chump bandwidth.
You don't understand OpenVPN. ;-)
OpenVPN operates very much in a Client-Server style, similar to many commercial VPN Concentrators. The server has a fixed IP address, and the clients connect to the server. After authenticating and establishing a connection, the server gives the client a DHCP-style assigned VPN IP address. Any communication done through the VPN is done between that IP and a tunnel-specific IP on the OpenVPN Server.
If you have fixed Peer-to-Peer tunnels, IPSec is the standard, and it works quite well. However, for ease of use, ease of deployment, ease of setup, and cases where you have dynamic clients accessing a single remote network, you really can't beat OpenVPN.
Did you use the OpenVPN provided scripts for managing the keys?
;-)
Because I managed to setup a new OpenVPN server from scratch, using certificates for authentication, in less than an hour this afternoon. Admittedly, I've used OpenVPN quite a bit in the past, but I did this setup from scratch, using the provided scripts, and it was *really* easy. Everything "just worked".
Additionally, OpenVPN also supports making use of PAM for authentication, giving you lots of other options. You can even setup OpenVPN to authenticate via RADIUS to an RSA Authentication Manager Server, using RSA SecurID keyfobs. It's pretty slick.
As far as OpenVPN you are deeply mistaken. It has nothing to do with IPSEC. It uses TLS over TCP or TLS over UDP. The second case requires some sequencing. None of the packet formats has anything to do with the IPSEC RFCs, the OS level abstractions have nothing to do with the RFCs and the keying is not anywhere near the madness specified in the IKE RFC.
"OpenVPN uses an industrial-strength security model designed to protect against both passive and active attacks. OpenVPN's security model is based on using SSL/TLS for session authentication and the IPSec ESP protocol for secure tunnel transport over UDP." -- http://openvpn.net/
IPSec's biggest problem is the complexity of the tunnel setup (IKE). The ESP protocol is pretty decent.
How is this a troll?
The guy suggested a legitimate tool to help the submitter manage their books. There was no demand that it have to be 100% free. The only requirement was that it be easy to use and support an open format. LibraryThing is easy to use, and allows you to export your data as CSV.
It's true that it won't help him "find" his books, but realistically, the only thing that'll help him with that is for him to get off his ass and apply some logical organization. It's as simple as dividing fiction and non-fiction (insert additional major categories as needed), and then arranging them alphabetically within their disciplines.
they usually have quite a bit of time on their hands anyway.
You have never worked as a System Administrator at a real company.
Low UID? That's not a low UID. Four digits is a low UID. ;-)
Yeah, it's too bad PHP doesn't support some sort of database abstraction layer. ;-)
Realistically, if you design an application from the start with even just a little bit of, well. . . design, and consideration for portability and future growth, database independance is not very difficult.
Unfortunately, it's been my experience that most people don't really think beyond the next few hours when they're coding, which means that making things better later on is a huge chore.
Yes, it's too bad there isn't a school with a long and impressive reputation for it's Computer Science department that offers online courses. That might help people take them more seriously.
No offense, but your comment is simplistic and silly. You're making unsubstantiated statements that don't really make sense and don't stand up to facts. Did you spend too much money on an Ivy League degree, and now you feel the need to justify the excessive cost?
One time scheduled actions is exactly what it exists for. I've been doing:
No offense, but that's both crap, and unrealistic.
I have to manage an Exchange server, and just recently we had a situation where a user was unable to access e-mail in order to set/change their Out of Office reply. The fact that there's no reasonable way for an admin to do that is just stupid. (Yes, there *are* ways to do it, but they are definitely not reasonable).
Also, in the real world, I'd love to see you tell an executive at the company you work for that they don't deserve e-mail because they're too dumb to manage their own Out of Office status. Somehow I don't think you'd be working there much longer if you did.
This is one (of many) places where Exchange fails to perform as it should.
If you *are* shopping for a portable, I'd suggest the GameBoy Advance SP, or DS.
Katamari Damacy has been announced for it, and they released FF Legends (FF1 & FF2) for it a little while ago.
For the price, you can't beat a GB SP right now, although the DS has the advantage of compatibility with more future games.
Yes, I find msyelf with a need to count all the rows in a table daily. Sometimes hourly. There's just so many places that I need that information. On the other hand, having the database enforce the consistency of my data. . . who needs that esoteric feature?
There are very good reasons for Postgres being slower at that, and it involves overall improved performance. If you *really* need that information that often (I can't honestly remember the last time I needed it), just set up a counter and a couple of triggers to increment/decrement it. Boom, issue resolved. Now you have your counts, but the rest of us, who don't care about that information, don't have to take the performance hit for it.
As for the dump/restore. . . for a non-trivial application, migrating to a new Database version is a rather large undertaking. Adding a few minutes to include a dump and restore is trivial next to the rest of the upgrade, in my experience.
In the case of Linux, those other people are your support channel. This is one of the many things that makes open source different. In the commercial arena, if I don't like a company's support channel, they aren't going to sell me anything. So if you don't like the users of some open source project, the same sort of decision ought to fall out of that.
Okay, I can understand that. And I think that's a valid argument for a product from a company, or for a smaller open source project.
But when you're talking one of the larger open source projects, or an entire Operating System (Linux), I think the argument falls apart. A single company or small project is likely to have a homogenous support base, and if you don't like it, there aren't a lot of alternatives.
But when you get into a larger project like Linux, that just doesn't apply. There are hundreds of companies offering support, and hundreds of different groups of people who are using it (and can be tapped for support). The variety of different groups of people here is enough that you should be able to find some element that you like.
There are just too many people using something the size of Linux, and it's impossible to generalize about the entire group (although the post I replied to definitely attempted to do just that!).
I can't appreciate it and yes I've used it. An editor that requires that you spend your time bouncing on the meta key fails one of the more important requirements of a text editor - that the editing keys need to be handily placed.
/bin/sh to point to dash (in fact, it prompts you with that question upon installation), and *poof*, now the traditional Bourne shell is your system shell.
That's a very subjective requirement. Personally, for my own use, I agree with it. That's why I use vi. But the fact that it fails one of your requirements doesn't mean that everyone else will view it the same.
With all due respect to your genius friend there are better programs for editing, reading news and coding. Ever heard of the unix principle of doing one thing and doing it well? Well GNU code usually does more than one thing...and it usually does them all badly. Emacs being a case in point.
There are better programs for you to do those things. He has taken advantage of the strengths of Emacs to customize and enhance it until it is the best program available for him to do those activities.
Regarding the Unix principle and Emacs. . . you really have to blame the Emacs users for that. Emacs started out as a fairly small and lightweight editor. At the begining, it was basically just a very basic editor with a built in lisp interpreter for extensibility. The majority of Emacs functionality has been implemented at a higher level, often by users, via elisp.
I was comparing the system shell of BSD and GNU/Linux. The advantage of sh over bash is not marginal when the system is spawning lots of shells ie. on boot-up. When I ran Linux the system took 3 times as long to come up compared to FreeBSD running the same softs and 2.4 performance wise was abysmal.
Yes, and it still isn't a valid comparison. You're comparing three BSD distributions, which are, despite their kernel level differences (and a few others), very homogenous, with all of the Linux distributions out there, which number in the hundreds, and are often very specialized.
To give one quick example of where it breaks down, I'll point to Debian, my Linux distribution of choice. Debian includes bash, true, but it also includes dash, formerly ash, which is the sh from NetBSD. It is trivial to set
As far as user shells go, bash is so far behind ksh in function it's not funny. I've already mentioned that bash is shot through with longstanding and seemingly intractable bugs. Which reminds me, the GNU readline library stinks too which is one reason why most developers choose to implement their own.
To each their own. I've tried ksh before, and been forced to use it on multiple occasions, and I didn't particularly care for it. Don't get me wrong, it's better than tcsh, and much better than csh or bourne shell, but it is lacking a number of features that bash supports, and I found it inconvenient and annoying.
I've actually used the GNU readline library before, too. It wasn't my favorite library to develop with, but I've used worse. And it generally gets the job done.
I looked over the hill some 4-5 years ago, saw that to become a GNU developer you have to have the right religious attitude irrespective of whether you can code or not.
That's a steaming pile of horse crap. You can do whatever the hell you want. If you want to sit at home on a Linux machine and develop proprietary software, you're free to do that. No one is gonig to break down your door and beat you with a penguin stick for it.
That was when I dumped GNU/Linux as even then it had become a ghetto for those with some sort of OS religious axe to grind. Now it's beyond a joke (21 kernel vulnerabilities in 3 months!) and the fact that you and others continue to argue that it is good is frankly bizarre.
Ah, so you choose what operating system you use by how much you like other people using it?
Use GNU code for religious reasons but don't use it if you've got work to do or care about using good tools.
The one bit of GNU code that really bugs me: Emacs
I have to admit, I found this to be an odd way of putting things.
Now, you may not be a fan of emacs, but first stating that you shouldn't use GNU code to get things done, and then holding up Emacs as an example, is ignorant at best. I am not personally a fan of Emacs, having discovered vi first, but I still can appreciate the power, flexibility, and usefulness of it.
A friend of mine is big an emacs fan. He uses it for text editing, e-mail, news reading, and coding. He's probably one of the top two or three coders I've ever met in my life. The guy is an absolute wiz. He's easily as productive as two or three normal programmers. And I've seen him do things in Emacs that nearly blows my mind.
You ask what Emacs is? It's probably the most flexible, powerful, and extensible text editor ever created. Although I dislike the implementation, the design theory behind it is beautiful, and has been successfully used by numerous other applications (build a small, fast kernel, or engine, that does implements the core functionality of your program, and build the rest in an extension/scripting language).
Also, a number of your other complaints and comparisons are marginally valid, at best. For example, comparing the Bourne Shell to bash is like comparing the old, original vi, to vim. Both vim and bash are much larger with respect to codebase and resource use, and both likely have more bugs. But they both also offer an immensely great level of functionality. (Although, in fact, both original Bourne shell and original vi have bugs ("features"), which have often been standardized despite their inconsistency.)
If you really want to stay stuck 10+ years in the past, with ancient (but possibly less buggy) software, that's cool. You have that choice.
Me, though. . . I'm looking over that hill there, wondering what we're going to see next.
No, just a very poorly worded title, which seems to be making the rounds.
To sum up the *truth*: Debian isn't dropping support for a bunch of architectures. It's dropping it's requirement that all architectures be synchronized and released as officially stable at the same time.
So in the future, a handful of Debian architectures will be regularly released as "stable", with a synchronized release. The other architectures will be allowed to come up with their own release timetables, based on need and ability.
Personally, I'd rather see them keep Arm as a primary architecture, and move IA64 to SCC. I think Arm will become an increasingly important architecture over the next few years, and I think IA64 will decline further. But, that's something that can be tackled post-sarge.
In a recent interview, one of the higher-ups at Red Hat said they were currently cleaning up the Netscape Directory Server source code in order to make it usable and buildable (he said that it currently required a very complex and involved build environment, and was being simplified).
He said that he expected it to be released within the next few months.
Really?
Can you point out who it was that "voted" for the broadcast flag?
Oh, wait, that's right. It wasn't voted on. It was mandated by the FCC.
Samsung Laser printers rock.
I have the ML-2552W, and I love it.
It does 1200x1200 dpi, built in Wifi and Ethernet, supports PCL6 and Postscript 3, 32MB of RAM standard, supports up to 160, sports a 266Mhz PPC CPU, and has built in duplexing.
I picked it up for $350.
According to the printer's status report, I've printed off 17334 pages so far. I've basically had no problems at all. I had it up and running on the LAN within an hour or so, with all of my computers (Linux, Windows, and an old UltraSparc) printing to it beautifuly.
Based on my good experience, a friend of mine picked up the same printer, and he's also raved about it. I don't remember what he paid for it, but I think it was a hair under $400.
If I were buying a new Laser printer, I would buy another one of these in a second. Depending on the features you need, the ML-2550 and ML-2551N may also be good options. The former is identical to the description above, but without the Wifi/Ethernet, the latter is identical except for without the Wifi. The prices for all three tend to fluctuate up and down. The ML-2551N seems to currently be the cheapest, found on PriceGrabber.com for $335 right now.
I know at one point I remember reading that this was being considered, and that Pixar might be involved. I recall that one of the high-up designers at Pixar said that Tron is the reason he got into the business, and that he'd love an opportunity to remake it.
I dunno if that'll happen, but I think there's a good chance it would end up a much better flick if Pixar ran with it. I'd be very curious to see what they could do.
Curious. . .
.
I have all three consoles, too. Plus a Dreamcast. And of course, a PC.
I have 5 XBox games, about 15 PS2 games, about 10 Dreamcast games. .
And 32 GameCube games.
There are a handful of awesome games on PS2, a couple of great ones for Xbox, and even a few for Dreamcast. But I've got over a dozen games on GameCube that I consider great.
It seems like the ratio of great games to average games is higher on GameCube. Xbox and PS2 are both about the same, but the PS2 has more great games by simple virtue of it having a *lot* more total games available.
I don't know what it is, but I simply seem to find more games that I truly enjoy on GameCube. To each their own, I suppose.
Actually, Nintendo pretty much dropped the censhorship thing with the introduction of the GameCube.
Games like Eternal Darkness: Sanity's Requiem and the Resident Evil games, along with many other adult (Rated 'M') games are available these days.
Another thing that people should read carefully is the privacy statement these guys post. There's some interesting stuff in there:
To create an account, we collect your name, email address, and a shipping address. You will also create a password that you may change in the Account page of our site. We use this information to set up your account, to send you a registration confirmation email and to log your shipping information so that we know where to send your order. We may also use your email address to send you information about new services, features, and special offers from us. Members may opt-out of receiving future mailings of this nature by following the relevant instructions articulated in the body of these promotional emails.
Translation: You give us your information. We then sell it to everyone who will pay us for it, and if you want to opt out of it, you'll have to opt out separately for every single one of the hundreds, if not thousands, of companies we sell you to.
We may work with other third party businesses using the personal information that you supply to us on the main signup page to bring selected retail opportunities to our members via direct mail, email and telemarketing. These businesses may include providers of direct marketing services and applications, including lookup and reference, data enhancement, suppression and validation and email marketing.
Translation: We will sell your information to known spammers, provided they pay us for it. We'll also sell it to telemarketers, junk mailers, and data whores who collect this kind of thing so they can resell it.
There is no way to deactivate an account; if you no longer wish to remain a part of a Gratis Internet website, simply stop logging in to your account. Gratis Internet will not share your information.
Translation: Be prepared for a lifetime of spam at a level well above what you're currently experiencing. And since we have it in the fine print, you can't stop us. Heck, we'll keep selling your information to spammers even after you're dead!
If we decide to change our privacy policy, we will post those changes to this privacy statement, the homepage, and other places we deem appropriate so that you are aware of what information we collect, how we use it, and under what circumstances, if any, we disclose it.
We reserve the right to modify this privacy statement at any time, so please review it frequently. If we make material changes to this policy, we will notify you here, by email, or by means of a notice on our web page.
Translation: We'll change our privacy statement whenever we feel like it, and we're not going to tell you about it. And since you can't delete, remove, or even deactivate an account, that means that we can pretty much do anything we want with your information and you'll probably never know about it. Doesn't that sound like fun?
This is really great news. Shadowrun has been one of my absolute favorite RPG's ever since it was released.
;-)
Admittedly, the first edition rules were a little rough around the edges, but the stories and setting were all absolutely top notch, and with the second edition rules streamlining a lot of things, I was really impressed.
I would love to see some of the other rulebooks released online, too. Now if I could just find someone to play this with. . . haven't played a table top RPG in years.