While 802.11n gives wireless a giant speed boost (theoretically 400+ Mbps), it's nowhere near the speeds of copper ethernet (1 Gbps, 10 Gbps for short runs) or fibre ethernet (10 Gbps+). And the transmission distances are much shorter (100m outside line-of-site for wireless vs. 70+ km for fibre).
Add on the inherent security weaknesses in wireless broadcast transmissions versus wired transmission between two end-points, and wireless cannot "replace" wired ethernet.
Is there a place for wireless? Sure. Should you rip out all the wiring in the building and start adding wireless antennae to all your servers? Definitely not.
In high school, I was positive I wanted to get into forensic chemistry. Hit university with a Chemistry Major. Two years later, I changed my major to General Science. A year later, switched it to Liberal Arts. A year later, switched it to Information Technology. 6 years of university, 4 changes of majors, and I'm finally doing what I'm good at and what I like.
A lot of the people I graduated high school went through the same "changing majors every year" transition until they finally hit upon what they were good at *and* what they liked doing.
How can you expect someone at 14-16 years of age to select what they will be doing 10 years into the future? Shoot, how can you expect someone in their 20s to know what they will be doing 10 years into the future?
If you're using tarballs, then check out that wonderful program called "split". It can hack up your files into any size you want. Just cat them together to re-assemble the original. With the wonders of pipes, you don't even need to save the "re-assembled" tarball to work on it.
Grab an NAS box and a cross-over cable. You can now access your files from a single box (some aren't much larger than an external HD case), from any OS with a NIC and network drive support.
WordPerfect's SGML-based file format was even better. You could save a file in WordPerfect 13 and open it in WordPerfect 7 without losing any formatting. And yet 13 had a lot of newer features that 7 didn't have. Now there was a nice format to work with.
The difference is that we use real/standard PC hardware running a general purpose, off-the-shelf OS.:) If you plunk a harddrive, CD-ROM, and floppy into our case, then you have a full-fledged PC.
Thin clients like the ones from IBM, HP, and Sun are closed boxes with specialised hardware in them that run specialised OSes and other software, and can only be used for connecting to a terminal server.
For the curious, our diskless workstations are:
BioStar GeForce 6100 AM2 motherboard (socket AM2)
1.8 GHz Sempron CPU
512 MB RAM
BIOS configured to give 64 MB to the video chipset
Some have a 3Com NIC installed as there's one revision of the nVidia NIC that doesn't work with any of the 2.6 Linux kernels
Yes, this is a "client/server" setup. However, you get all the benefits of a thin client setup, without any of the hassles.
Software is installed once on the server, and all the clients pick it up. There's no harddrive in the client. But all software is run locally -- which means 100+ clients can all run the same app at the same time without touching/taxing the server's CPU/RAM. The really nice thing is that with a diskless setup, you can have full-motion video without bringing the network to a halt. You can 50+ stations watching "Elephant's Dream" simultaneously and barely even notice the network load.
That's the beauty of Linux (and the BSDs) and X. It's all network transparent. Doesn't matter where the files are located, the OS treats it like it's local. Mount everything (including the root filesystem) over NFS and you can treat the machine as if it had a harddrive. There's a second or two added to program load time due to transferring it over the network, but that's it.
Terminal servers are useful if you have weak clients ( 800MHz P3 CPU, 256 MB RAM, crappy video) and you don't need full-motion, 30fps video and/or high quality sound. And if you only need a handful of clients. With terminal servers, the bottleneck is the network. 100 Mbps to the server isn't enough, and even gigabit to the server can be tight.
(Although I would also like to see specifications on exactly how many systems they migrated, and what distros they used)
37 elementary schools with 30 computers in the lab == >900 client workstations in the elementary schools. Most of these schools have ~20 working computers (if they were lucky) running a hodge-podge of Windows 3.1, 95, and 98. Now they all run Linux.
1 secondary school with 110 computers (every computer in the school, including admin/office computers). These were running Windows 98 and XP previously.
See a previous post for the versions of Linux that have been used.
To be pedantic, these are neither "dumb terminals", "x terminals", nor "thin clients". These are diskless workstations.
Our original implementation back in 2001-ish was mostly a thin client, dumb terminal setup. The client systems had no harddrives, booted via etherboot, mounted their filesystems over the network via NFS, and executed all software on the server with just the X display shot back. The keyboard, the mouse, the NIC, and the videocard were pretty much all that were used. We found this setup to be very limiting (try having 30 stations play Tux Typing simultaneously -- be prepared for a lot of frustrated kids as the video chunks along with sound unusable).
To work around the networking issues (and to make multimedia work), we moved to a hybrid setup where the client systems still had to harddrives, still booted via etherboot, still mounted their filesystems over the network via NFS, but programs were executed locally using the client's CPU, RAM, videocard, soundcard, etc. We developed a system where we could specify the CPU/RAM requirements for a program and if the client didn't meet them, then it would execute that program on the server with the X display shot back.
The current implementation (that we've successfully rolled out to one secondary and one elementary, with more scheduled for this summer) is a diskless workstation setup. The clients still don't have harddrives, still boot off the network and all that, but everything is run locally on the workstation using its CPU, RAM, video, sound, etc. Except for the fact that it mounts all the filesystems from the server, it looks, acts, works just like a regular "fat client" PC.
However, in order not to confuse people in the district, we've taken to just calling them "thin clients", since that's what they started out as and that's what people understand (no one seems to understand the difference between thin client and diskless client).
What I would find interesting is what they found the optimal size for the servers, how many terminals they support, how the ram and the drives were configured optimally, are there dual Gigabit nics, or do they find the network doesn't saturate?
If going the thin-client/terminal route (where everything runs on the server and the "client" is really only a keyboard, mouse, monitor, and NIC), then you need a *VERY* beefy server with lots of CPU, RAM, and network throughput. We found that a dual-AthlonMP 2.0 GHz system with 4 GB of RAM is enough for 30 stations, but just barely. The faster the NIC, the better the experience.
If going the (in our experience, better) diskless route, then you need a fast network connection and lots of disk space on the server, but CPU and RAM aren't as important. We have one secondary school where the server is a dual-Opteron 2.0 GHz server with 4 GB RAM, an 800 GB RAID5 array, and a single Gigabit NIC. It supports 110 diskless workstation without any issues. Most of the time, it's idle.
We're implementing the same server in another secondary school this summer that will support 242 diskless clients. We're going to bond two of the gigabit NICs into a single virtual channel, but the rest of the server is the same.
We custom-build our servers to make sure we get fully-supported hardware. Our current server spec is:
Tyan Thunder K8SD-Pro motherboard (S2882)
2x Opteron 24x CPUs (2+ GHz) (motherboard can handle dual-core CPUs as well)
4 GB ECC DDR-SDRAM (motherboad can handle up to 32 GB)
3Ware Escalade 9550SX PCI-X RAID controller
400+ GB harddrives
2x redundant PSUs
Case depends on whether it's going to be rackmounted to standalone.
That's fine up to a point; the majority of businesses still use MS Office and windows and will want to see that experience, and if you completely replace everything with linux or other free alternatives you're just creating another monoculture, and push a free-only view; which is, to my mind, just as bad.
Schools should not teach specific applications... they should teach skills that can be applied to groups of software.
What I'd love to see, is a Business Ed class where they use multiple office suites throughout the course, teaching skills like text layout, letter/memo formats, etc in one suite, then asking for the assignment to be completed using a different suite.
Schools are not "employee training grounds". We should be teaching our kids how to learn, how to transfer knowledge, how to help themselves... not teaching them "click in this menu to bold text, this button for left justified, etc".
The initial version of our XTerminal server used RedHat Linux 7.x for the server and the client. This was in the 2001-2002-ish timeframe.
An updated version of our XTerminal server used RedHat Linux 7.x for the base server, with a chroot install of Debian Etch (testing back then) for the bulk of the client programs. This was in the 2003-2006-ish timeframe.
The latest version of our XTerminal server uses Debian Etch for the base OS, with a VServer running Debian Etch for the clients.
Yes, congratulations. However, they are building on years of effort by the Kindergarten to 12th grade Linux project, and other such projects. The K12Linux Project was originally started for the Multnomah County Education Service District, using hardware donated by Intel. (Intel does some of its processor design in a big facility which is also in Portland, Oregon, USA.)
If the LTSP project grew out of the K12LTSP project, then you are correct. However, IIRC, K12LTSP grew out of the LTSP project. We have never in the past used or even looked at anything related to the K12LTSP project nor the K12Linux project.
We started with a modified and highly customised version of LTSP 2.0 and initially configured the labs as thin-client labs where just about everything ran on the server (using P2 systems with 128 MB of RAM). As the clients became more powerful (P3 with 256 MB RAM) we moved to a hybrid setup where the window manager ran on the client, most programs ran on the client, and only the large apps like OpenOffice.org ran on the server. Recently, we replaced all the computers in all the elementary school labs with P3 systems w/512 MB RAM. Everything runs on the client now, and we've moved to a diskless model (no longer thin-client).
With our latest revision of the server, we've completely stopped using anything related to LTSP. We're using a diskless, network boot model, where everything is mounted over NFS and everything runs on the client. The clients in the elementary schools are P3 800+ MHz systems with 512 MB RAM, and the clients in the secondary schools are 1.8 GHz Sempron systems with 512 MB RAM and 64 MB nVidia GeForce 6100 videocards.
The "problem" with gaming nowadays, IMO, is that it is too realistic. Everything is basically a simulation now. There are no sports "games", they're all league simulators. There are no racing "games", they're all driving simulators. For some genres, realism is good (horror, FPS, suspense games). For others, it's not so much.
Where are the games like Basewars (robot baseball where you have to fight to determine safe/out), Baseball All-Stars (where you get super-powers), all the racing games where you could go full-throttle around the course bouncing off walls with impunity, the aerial combat games like the Tie Fighter series or Secret Weapons Over Normandy, where you could fly without worrying about the laws of physics and whether or not your ailerons are up or down, and the like? Games that did not simulate reality, where you could escape reality, and just have fun for a few hours?
Simulation games are nice, like the original SimCity, but things have been taken too far to the "uber-realistic" extreme where you end up micro-managing everything.
Game systems of yore didn't have the CPU/graphics power to simulate reality, so the games were more imaginative, breaking free of reality. IMO/E, that made games a lot more fun to play.
How (other than upbringing and socialisation) can you possibly find "32 == freezing" sensible?
Everyone knows that when water freezes, it's cold outside. And since 0C is the freezing temperature of water, it makes sense that temperatures above 0C are warm, and temps below 0C are cold.
I hear US weather reports, and have absolutely no idea what they are talking about. "Tomorrow will be in the mid-60s better put on a sweater", "Tomorrow will be in the mid-70s better put on shorts", "Tomorrow will be in the low-thirties better bundle up".
L/100 Km has got to be the stupidest way to measure gas milage. How the hell is anyone supposed to convert "7.1 L / 100 Km" into a useful measure? If you have a 35 L tank, how far can you go on a single tank of gas?
Using Km / L (similar to miles/gal), you can very easily determine how far you can drive on a tank of gas. You can also guesstimate how far you've driven based on fuel usage. It's very easy to do calculations using this number. Oops! That sounds user-friendly... no wonder you don't find it anywhere.
The people who developed "L / 100 Km" should be taken out back and shot!!
Vonage (Canada) has a no-hassle cancellation process. We just canceled our account on Wednesday, after using it for 13 months. The process was "call 1-800 number, transfer to account services, ask to cancel account, get confirmation via e-mail". The account rep asked if I wanted to just put the account on hold for 6 months (no fees, no outgoing calls, unlimited incoming calls), but we canceled instead. Including hold times, it took less than 15 minutes.
The standard seems to be heading towards 64-bit processors...
The standard *is* 64-bit CPUs. It's virtually impossible to buy a pure 32-bit CPU new. P3s are no longer for sale. P4s are no longer available in a lot of places. The Pentium-M/Core CPU is soon to be phased out. The AMD Duron and early Semprons are no longer available. Everything that is available (Xeon, Core2, Athlon64, Turion, Sempron, Opteron) are all 64-bit CPUs. I'm pretty sure even the Celerons now are 64-bit.
However, they can all run 32-bit software, as well as 64-bit software. So the question is not whether to buy 64-bit hardware (yes, you should) but whether to buy/use 64-bit software.
On the desktop, I'd say no. Unless you are doing something that requires more than 4 GB of RAM, there's really no need to run a 64-bit desktop OS.
On the server, I've say yes. Even if you aren't using more than 4 GB of RAM now, it much nicer to just pop the case open, add more RAM, and keep going... without having to reinstall the OS and apps.
You don't need any extra software to burn CDs in Windows XP. Windows Explorer includes that option. Right click on files, use Send To -> CD-RW Drive (or whatever Windows decides to call you CD/DVD-RW drive). That creates a virtual CD that you can add software to. Then, in Explorer, just right-click on that virtual drive and tell it to burn a CD.
Haven't tried with.iso files, as I prefer Nero (which is not hard to use - drag 'n drop files from the explorer pane to the blank CD pane, click Burn icon).
I've also yet to see Nero 5, 6, or 7 use more than 30 MB of RAM, even when burning DVDs. The longest I've waited for a data DVD-R to burn is 15 minutes, and that's because I pull files off a file-server running Samba (so I dial down the burn speed).
While Windows XP is not the greatest OS out there, and is not the most fun to use, it's not nearly as bad as you make it out to be (at least in this area).
This is nothing more than a cop-out. They could lock these in the firmware and not expose that functionality in the driver. Instead, they put it all in the driver and use that as an excuse to not open-source the driver.
However, at least with the Intel drivers, the OpenBSD guys have shown that the driver can *very* easily be tricked into breaking the FCC "rules". So what's the point in having it closed again?
Put items that should not be changeable in the firmware. Put items that should be changeable in the driver. How hard is that??
You do need to hunt down repositories for Debian, if you want software that isn't included in the standard repos. For instance, at the time of writing for that thread (July 2005) you could not get Java, Madwifi, or KDE 3.4+ in the standard repos. To get those, I had to search the web for custom repos to use with Sarge. Not a lot of fun for a Debian newbie.
Debian may have the highest number of packages available, but it does not have the highest number of applications. A lot of the packages in the Debian repos are for the libs that come with apps, and for multiple versions of the same app with various features enabled or disabled. If you take out all those duplicates, you end up with a lot fewer apps. A lot, yes, but probably not the most.
At the time that I wrote that piece, Ubuntu was a horrid little thing that was just starting out. Kubuntu didn't exist yet, and being a KDE user, why would I try Ubuntu?
Wireless is the worst grafted-on technology in the Linux world. There are multiple wireless networking stacks, multiple WPA supplicants, multiple commands for working with wired connections, wireless connections, and device-specific options. And Debian was (at the time) one of the worst for wireless support -- there was none officially in Sarge for madwifi or wpa_supplicant. Now, in Etch, things are a bit better, but nowhere near the level in FreeBSD. Why is there an ifconfig, a iwconfig, and driver-specific commands to work with wireless links? In FreeBSD, there's only ifconfig since they are all network interfaces, there's only a single networking stack that all the devices use. There a single config file to manage the wireless side of things.
I've become proficient with Debian in the year and a bit since I posted that, but Debian in particular and Linux in general remains a conglomeration of a bunch of hacked together software projects without an overarching feeling of togetherness or unity to it. There's no cohesiveness to "Linux" even in some of the distros.
Ubuntu is moving along nicely in that area, but that only drives home the notion that there is no Linux OS, just a hodge podge of OSes built around it, each with their own ideosyncracies, and the only way to get anything done is to standardise on a single distro. People need to get out of the "Linux" mindset and into the "Ubuntu" or "Fedora" or "Debian" or "Gentoo" mindset. Once that happens, then things will probably get better... or else it will cause the splintering of "Linux" like the splintering of Unix back in the day.
And, yes, upgrading a couple apps can result in an upgrade to the entire OS. I've done it a few times. I'll never understand the whole Linux distro concept of "the OS and apps are one". Why do I need to upgrade to Debian Etch in order to run KDE 3.5? I can run KDE 3.5 on FreeBSD 4.11, 5.5, and 6.1, it doesn't require an OS upgrade to run newer apps.
While we haven't hit the 100,000 account mark as yet (just topping 5,000 right now) we do have a very complex mail setup: 1 mail gateway, 4 main mail servers (transitioning to one cluster setup) with separate @server.domain.com addresses, 10 secondary school mail servers with their own @server.domain.com addresses, everyone's official e-mail address is @domain.com. Using Postfix' canonical maps (and soon generic maps), we're able to move accounts from one server to another without ever having the public know. We're also able to use LDAP and MySQL lookups to figure out where the message should go. It was really quite simple. Required adding three lines to the main.cf, add a couple rules to a couple text files, and configure a mapping between internal and external addresses. Without ever having to learn M4, short two-letter options, and other nasty "sendmail-isms".
We push between 2 and 3 million messages a month through our mail gateway (which also handles spam and virus filtering using amavisd-new, spamassassin, razor, pyzor, dcc, clamav, commandav, whitelists, and more). System is a dual-AthlonMP 2200+ with 3.5 GB RAM running FreeBSD 5.4 (extreme overkill for our needs, but at least we won't have to upgrade anytime soon).
The problem with sendmail is that you *need* a good book beside you to configure it properly. All the other MTAs use plain English configuration terms, and have useful man pages. Books are optional, not required, to get a good, secure, fast, mail setup.
Slashdot Mirror
While 802.11n gives wireless a giant speed boost (theoretically 400+ Mbps), it's nowhere near the speeds of copper ethernet (1 Gbps, 10 Gbps for short runs) or fibre ethernet (10 Gbps+). And the transmission distances are much shorter (100m outside line-of-site for wireless vs. 70+ km for fibre).
Add on the inherent security weaknesses in wireless broadcast transmissions versus wired transmission between two end-points, and wireless cannot "replace" wired ethernet.
Is there a place for wireless? Sure. Should you rip out all the wiring in the building and start adding wireless antennae to all your servers? Definitely not.
No kidding!
In high school, I was positive I wanted to get into forensic chemistry. Hit university with a Chemistry Major. Two years later, I changed my major to General Science. A year later, switched it to Liberal Arts. A year later, switched it to Information Technology. 6 years of university, 4 changes of majors, and I'm finally doing what I'm good at and what I like.
A lot of the people I graduated high school went through the same "changing majors every year" transition until they finally hit upon what they were good at *and* what they liked doing.
How can you expect someone at 14-16 years of age to select what they will be doing 10 years into the future? Shoot, how can you expect someone in their 20s to know what they will be doing 10 years into the future?
If you're using tarballs, then check out that wonderful program called "split". It can hack up your files into any size you want. Just cat them together to re-assemble the original. With the wonders of pipes, you don't even need to save the "re-assembled" tarball to work on it.
Grab an NAS box and a cross-over cable. You can now access your files from a single box (some aren't much larger than an external HD case), from any OS with a NIC and network drive support.
RTFA, it mentions just that in there. :) Webkit will be in QT 4.4 (or thereabouts).
WordPerfect's SGML-based file format was even better. You could save a file in WordPerfect 13 and open it in WordPerfect 7 without losing any formatting. And yet 13 had a lot of newer features that 7 didn't have. Now there was a nice format to work with.
The difference is that we use real/standard PC hardware running a general purpose, off-the-shelf OS. :) If you plunk a harddrive, CD-ROM, and floppy into our case, then you have a full-fledged PC.
Thin clients like the ones from IBM, HP, and Sun are closed boxes with specialised hardware in them that run specialised OSes and other software, and can only be used for connecting to a terminal server.
For the curious, our diskless workstations are:
BioStar GeForce 6100 AM2 motherboard (socket AM2)
1.8 GHz Sempron CPU
512 MB RAM
BIOS configured to give 64 MB to the video chipset
Some have a 3Com NIC installed as there's one revision of the nVidia NIC that doesn't work with any of the 2.6 Linux kernels
Freddie Cash
SD73 Network Support
Yes, this is a "client/server" setup. However, you get all the benefits of a thin client setup, without any of the hassles.
:)
Software is installed once on the server, and all the clients pick it up. There's no harddrive in the client. But all software is run locally -- which means 100+ clients can all run the same app at the same time without touching/taxing the server's CPU/RAM. The really nice thing is that with a diskless setup, you can have full-motion video without bringing the network to a halt. You can 50+ stations watching "Elephant's Dream" simultaneously and barely even notice the network load.
That's the beauty of Linux (and the BSDs) and X. It's all network transparent. Doesn't matter where the files are located, the OS treats it like it's local. Mount everything (including the root filesystem) over NFS and you can treat the machine as if it had a harddrive. There's a second or two added to program load time due to transferring it over the network, but that's it.
Terminal servers are useful if you have weak clients ( 800MHz P3 CPU, 256 MB RAM, crappy video) and you don't need full-motion, 30fps video and/or high quality sound. And if you only need a handful of clients. With terminal servers, the bottleneck is the network. 100 Mbps to the server isn't enough, and even gigabit to the server can be tight.
Diskless setups are where it's at.
Freddie Cash
SD73 Network Support
(Although I would also like to see specifications on exactly how many systems they migrated, and what distros they used)
37 elementary schools with 30 computers in the lab == >900 client workstations in the elementary schools. Most of these schools have ~20 working computers (if they were lucky) running a hodge-podge of Windows 3.1, 95, and 98. Now they all run Linux.
1 secondary school with 110 computers (every computer in the school, including admin/office computers). These were running Windows 98 and XP previously.
See a previous post for the versions of Linux that have been used.
Freddie Cash
SD73 Network Support
To be pedantic, these are neither "dumb terminals", "x terminals", nor "thin clients". These are diskless workstations.
Our original implementation back in 2001-ish was mostly a thin client, dumb terminal setup. The client systems had no harddrives, booted via etherboot, mounted their filesystems over the network via NFS, and executed all software on the server with just the X display shot back. The keyboard, the mouse, the NIC, and the videocard were pretty much all that were used. We found this setup to be very limiting (try having 30 stations play Tux Typing simultaneously -- be prepared for a lot of frustrated kids as the video chunks along with sound unusable).
To work around the networking issues (and to make multimedia work), we moved to a hybrid setup where the client systems still had to harddrives, still booted via etherboot, still mounted their filesystems over the network via NFS, but programs were executed locally using the client's CPU, RAM, videocard, soundcard, etc. We developed a system where we could specify the CPU/RAM requirements for a program and if the client didn't meet them, then it would execute that program on the server with the X display shot back.
The current implementation (that we've successfully rolled out to one secondary and one elementary, with more scheduled for this summer) is a diskless workstation setup. The clients still don't have harddrives, still boot off the network and all that, but everything is run locally on the workstation using its CPU, RAM, video, sound, etc. Except for the fact that it mounts all the filesystems from the server, it looks, acts, works just like a regular "fat client" PC.
However, in order not to confuse people in the district, we've taken to just calling them "thin clients", since that's what they started out as and that's what people understand (no one seems to understand the difference between thin client and diskless client).
Freddie Cash
SD73 Network Support
What I would find interesting is what they found the optimal size for the servers, how many terminals they support, how the ram and the drives were configured optimally, are there dual Gigabit nics, or do they find the network doesn't saturate?
If going the thin-client/terminal route (where everything runs on the server and the "client" is really only a keyboard, mouse, monitor, and NIC), then you need a *VERY* beefy server with lots of CPU, RAM, and network throughput. We found that a dual-AthlonMP 2.0 GHz system with 4 GB of RAM is enough for 30 stations, but just barely. The faster the NIC, the better the experience.
If going the (in our experience, better) diskless route, then you need a fast network connection and lots of disk space on the server, but CPU and RAM aren't as important. We have one secondary school where the server is a dual-Opteron 2.0 GHz server with 4 GB RAM, an 800 GB RAID5 array, and a single Gigabit NIC. It supports 110 diskless workstation without any issues. Most of the time, it's idle.
We're implementing the same server in another secondary school this summer that will support 242 diskless clients. We're going to bond two of the gigabit NICs into a single virtual channel, but the rest of the server is the same.
We custom-build our servers to make sure we get fully-supported hardware. Our current server spec is:
Tyan Thunder K8SD-Pro motherboard (S2882)
2x Opteron 24x CPUs (2+ GHz) (motherboard can handle dual-core CPUs as well)
4 GB ECC DDR-SDRAM (motherboad can handle up to 32 GB)
3Ware Escalade 9550SX PCI-X RAID controller
400+ GB harddrives
2x redundant PSUs
Case depends on whether it's going to be rackmounted to standalone.
Freddie Cash
SD73 Network Support
That's fine up to a point; the majority of businesses still use MS Office and windows and will want to see that experience, and if you completely replace everything with linux or other free alternatives you're just creating another monoculture, and push a free-only view; which is, to my mind, just as bad.
... they should teach skills that can be applied to groups of software.
... not teaching them "click in this menu to bold text, this button for left justified, etc".
Schools should not teach specific applications
What I'd love to see, is a Business Ed class where they use multiple office suites throughout the course, teaching skills like text layout, letter/memo formats, etc in one suite, then asking for the assignment to be completed using a different suite.
Schools are not "employee training grounds". We should be teaching our kids how to learn, how to transfer knowledge, how to help themselves
The initial version of our XTerminal server used RedHat Linux 7.x for the server and the client. This was in the 2001-2002-ish timeframe.
An updated version of our XTerminal server used RedHat Linux 7.x for the base server, with a chroot install of Debian Etch (testing back then) for the bulk of the client programs. This was in the 2003-2006-ish timeframe.
The latest version of our XTerminal server uses Debian Etch for the base OS, with a VServer running Debian Etch for the clients.
Freddie Cash
SD73 Network Support
Yes, congratulations. However, they are building on years of effort by the Kindergarten to 12th grade Linux project, and other such projects. The K12Linux Project was originally started for the Multnomah County Education Service District, using hardware donated by Intel. (Intel does some of its processor design in a big facility which is also in Portland, Oregon, USA.)
If the LTSP project grew out of the K12LTSP project, then you are correct. However, IIRC, K12LTSP grew out of the LTSP project. We have never in the past used or even looked at anything related to the K12LTSP project nor the K12Linux project.
We started with a modified and highly customised version of LTSP 2.0 and initially configured the labs as thin-client labs where just about everything ran on the server (using P2 systems with 128 MB of RAM). As the clients became more powerful (P3 with 256 MB RAM) we moved to a hybrid setup where the window manager ran on the client, most programs ran on the client, and only the large apps like OpenOffice.org ran on the server. Recently, we replaced all the computers in all the elementary school labs with P3 systems w/512 MB RAM. Everything runs on the client now, and we've moved to a diskless model (no longer thin-client).
With our latest revision of the server, we've completely stopped using anything related to LTSP. We're using a diskless, network boot model, where everything is mounted over NFS and everything runs on the client. The clients in the elementary schools are P3 800+ MHz systems with 512 MB RAM, and the clients in the secondary schools are 1.8 GHz Sempron systems with 512 MB RAM and 64 MB nVidia GeForce 6100 videocards.
Freddie Cash
SD73 Network Support
It's also available in MacOS X.
Linux is the only OS that is not interested in it, instead (as per normal) doing their own thing.
The "problem" with gaming nowadays, IMO, is that it is too realistic. Everything is basically a simulation now. There are no sports "games", they're all league simulators. There are no racing "games", they're all driving simulators. For some genres, realism is good (horror, FPS, suspense games). For others, it's not so much.
Where are the games like Basewars (robot baseball where you have to fight to determine safe/out), Baseball All-Stars (where you get super-powers), all the racing games where you could go full-throttle around the course bouncing off walls with impunity, the aerial combat games like the Tie Fighter series or Secret Weapons Over Normandy, where you could fly without worrying about the laws of physics and whether or not your ailerons are up or down, and the like? Games that did not simulate reality, where you could escape reality, and just have fun for a few hours?
Simulation games are nice, like the original SimCity, but things have been taken too far to the "uber-realistic" extreme where you end up micro-managing everything.
Game systems of yore didn't have the CPU/graphics power to simulate reality, so the games were more imaginative, breaking free of reality. IMO/E, that made games a lot more fun to play.
How (other than upbringing and socialisation) can you possibly find "32 == freezing" sensible?
Everyone knows that when water freezes, it's cold outside. And since 0C is the freezing temperature of water, it makes sense that temperatures above 0C are warm, and temps below 0C are cold.
I hear US weather reports, and have absolutely no idea what they are talking about. "Tomorrow will be in the mid-60s better put on a sweater", "Tomorrow will be in the mid-70s better put on shorts", "Tomorrow will be in the low-thirties better bundle up".
Boggles the mind.
L/100 Km has got to be the stupidest way to measure gas milage. How the hell is anyone supposed to convert "7.1 L / 100 Km" into a useful measure? If you have a 35 L tank, how far can you go on a single tank of gas?
... no wonder you don't find it anywhere.
Using Km / L (similar to miles/gal), you can very easily determine how far you can drive on a tank of gas. You can also guesstimate how far you've driven based on fuel usage. It's very easy to do calculations using this number. Oops! That sounds user-friendly
The people who developed "L / 100 Km" should be taken out back and shot!!
Vonage (Canada) has a no-hassle cancellation process. We just canceled our account on Wednesday, after using it for 13 months. The process was "call 1-800 number, transfer to account services, ask to cancel account, get confirmation via e-mail". The account rep asked if I wanted to just put the account on hold for 6 months (no fees, no outgoing calls, unlimited incoming calls), but we canceled instead. Including hold times, it took less than 15 minutes.
The standard seems to be heading towards 64-bit processors ...
The standard *is* 64-bit CPUs. It's virtually impossible to buy a pure 32-bit CPU new. P3s are no longer for sale. P4s are no longer available in a lot of places. The Pentium-M/Core CPU is soon to be phased out. The AMD Duron and early Semprons are no longer available. Everything that is available (Xeon, Core2, Athlon64, Turion, Sempron, Opteron) are all 64-bit CPUs. I'm pretty sure even the Celerons now are 64-bit.
However, they can all run 32-bit software, as well as 64-bit software. So the question is not whether to buy 64-bit hardware (yes, you should) but whether to buy/use 64-bit software.
On the desktop, I'd say no. Unless you are doing something that requires more than 4 GB of RAM, there's really no need to run a 64-bit desktop OS.
On the server, I've say yes. Even if you aren't using more than 4 GB of RAM now, it much nicer to just pop the case open, add more RAM, and keep going ... without having to reinstall the OS and apps.
You don't need any extra software to burn CDs in Windows XP. Windows Explorer includes that option. Right click on files, use Send To -> CD-RW Drive (or whatever Windows decides to call you CD/DVD-RW drive). That creates a virtual CD that you can add software to. Then, in Explorer, just right-click on that virtual drive and tell it to burn a CD.
.iso files, as I prefer Nero (which is not hard to use - drag 'n drop files from the explorer pane to the blank CD pane, click Burn icon).
Haven't tried with
I've also yet to see Nero 5, 6, or 7 use more than 30 MB of RAM, even when burning DVDs. The longest I've waited for a data DVD-R to burn is 15 minutes, and that's because I pull files off a file-server running Samba (so I dial down the burn speed).
While Windows XP is not the greatest OS out there, and is not the most fun to use, it's not nearly as bad as you make it out to be (at least in this area).
This is nothing more than a cop-out. They could lock these in the firmware and not expose that functionality in the driver. Instead, they put it all in the driver and use that as an excuse to not open-source the driver.
However, at least with the Intel drivers, the OpenBSD guys have shown that the driver can *very* easily be tricked into breaking the FCC "rules". So what's the point in having it closed again?
Put items that should not be changeable in the firmware. Put items that should be changeable in the driver. How hard is that??
I believe you're thinking of the tag/signature that made the rounds back in the late 90s that looked something like this:
:)
Linux: For those that hate Windows
FreeBSD: For those that love Unix
Not sure where it first cropped up, but it's certainly remained true.
You do need to hunt down repositories for Debian, if you want software that isn't included in the standard repos. For instance, at the time of writing for that thread (July 2005) you could not get Java, Madwifi, or KDE 3.4+ in the standard repos. To get those, I had to search the web for custom repos to use with Sarge. Not a lot of fun for a Debian newbie.
... or else it will cause the splintering of "Linux" like the splintering of Unix back in the day.
Debian may have the highest number of packages available, but it does not have the highest number of applications. A lot of the packages in the Debian repos are for the libs that come with apps, and for multiple versions of the same app with various features enabled or disabled. If you take out all those duplicates, you end up with a lot fewer apps. A lot, yes, but probably not the most.
At the time that I wrote that piece, Ubuntu was a horrid little thing that was just starting out. Kubuntu didn't exist yet, and being a KDE user, why would I try Ubuntu?
Wireless is the worst grafted-on technology in the Linux world. There are multiple wireless networking stacks, multiple WPA supplicants, multiple commands for working with wired connections, wireless connections, and device-specific options. And Debian was (at the time) one of the worst for wireless support -- there was none officially in Sarge for madwifi or wpa_supplicant. Now, in Etch, things are a bit better, but nowhere near the level in FreeBSD. Why is there an ifconfig, a iwconfig, and driver-specific commands to work with wireless links? In FreeBSD, there's only ifconfig since they are all network interfaces, there's only a single networking stack that all the devices use. There a single config file to manage the wireless side of things.
I've become proficient with Debian in the year and a bit since I posted that, but Debian in particular and Linux in general remains a conglomeration of a bunch of hacked together software projects without an overarching feeling of togetherness or unity to it. There's no cohesiveness to "Linux" even in some of the distros.
Ubuntu is moving along nicely in that area, but that only drives home the notion that there is no Linux OS, just a hodge podge of OSes built around it, each with their own ideosyncracies, and the only way to get anything done is to standardise on a single distro. People need to get out of the "Linux" mindset and into the "Ubuntu" or "Fedora" or "Debian" or "Gentoo" mindset. Once that happens, then things will probably get better
And, yes, upgrading a couple apps can result in an upgrade to the entire OS. I've done it a few times. I'll never understand the whole Linux distro concept of "the OS and apps are one". Why do I need to upgrade to Debian Etch in order to run KDE 3.5? I can run KDE 3.5 on FreeBSD 4.11, 5.5, and 6.1, it doesn't require an OS upgrade to run newer apps.
While we haven't hit the 100,000 account mark as yet (just topping 5,000 right now) we do have a very complex mail setup: 1 mail gateway, 4 main mail servers (transitioning to one cluster setup) with separate @server.domain.com addresses, 10 secondary school mail servers with their own @server.domain.com addresses, everyone's official e-mail address is @domain.com. Using Postfix' canonical maps (and soon generic maps), we're able to move accounts from one server to another without ever having the public know. We're also able to use LDAP and MySQL lookups to figure out where the message should go. It was really quite simple. Required adding three lines to the main.cf, add a couple rules to a couple text files, and configure a mapping between internal and external addresses. Without ever having to learn M4, short two-letter options, and other nasty "sendmail-isms".
We push between 2 and 3 million messages a month through our mail gateway (which also handles spam and virus filtering using amavisd-new, spamassassin, razor, pyzor, dcc, clamav, commandav, whitelists, and more). System is a dual-AthlonMP 2200+ with 3.5 GB RAM running FreeBSD 5.4 (extreme overkill for our needs, but at least we won't have to upgrade anytime soon).
The problem with sendmail is that you *need* a good book beside you to configure it properly. All the other MTAs use plain English configuration terms, and have useful man pages. Books are optional, not required, to get a good, secure, fast, mail setup.