We're using OpenOffice.org in all of our elementary schools (K-7) with great success. Some teachers are using KWrite with the younger (K-3) students. Depending on the teachers knowledge, the students are doing some amazing things with OpenOffice.org (pamphlets, animated slideshows, newsletters, etc).
The secondary schools are a much harder sell due to teacher reluctance. Too many teachers are hung up on the "industry uses Office, therefore we must teach Office" mantra, which is horse shit.
We should be teaching the students how to use proper formatting, what the different styles of letters and memos are, how to layout a spreadsheet and use formulas, how to do proper page layout with mixed text and images, etc. Use one or two or three different office suites, to show you know the skills and not just where the options are in the menu of that one app.
It's understandable for the teachers that have a lot of teaching resources and course plans already tailored to a specific app. But that should not prevent them from installing other office suites, and slowly making them ofice suite agnostic. Of course, since very few teachers in this district communicate with others or share lesson plans, this will never happen.:(
Schools should *NOT* be teaching specific applications. Courses should not be geared toward one specific version of an application.
Instead, schools should be teaching skills that can be applied to all similar programs.
For instance, there should not be an "MS Word" course; there should be a "Wordprocessing" course. Students should be taught what the different formatting options are, when to use them, what the different letter and memo formats are, how to insert images and make text flow around them, etc. In a perfect world, they would use more than one office suite in the course, to see how the different applications do the same thing.
Public schools are *NOT* trades schools, they are *NOT* training schools for companies. The point of school is *NOT* to get a job. The point is to learn, to expand your intellect. What you do with that knowledge is up to you. But school should not be a training ground for specific jobs.
It's the same with Office. Unless you have the Office fast startup thingy loading at login, it takes a long time to load Word or Excel or even Outlook. Double-clicking on a document to auto-load it in Word takes even longer.
Loading the fast startup thingy for OO.org or Office makes things a lot faster, at the cost of quite a bit of RAM. It's a trade-off, and can either be very useful (need to access documents right after logging in) or a pain (losing all that RAM when you don't need to edit docs).
We haven't implemented it just yet (waiting for the local telco to install the needed incoming/outgoing lines to the school board office), but we're going with Hylafax as well.
For incoming faxes, we have 50 fax numbers mapped to 6 incoming DID lines, connected to some fancy fax device connect to a Hylafax server. That converts the incoming fax to an e-mail with an attached PDF, and drops it into a site e-mail box. Secretaries at each site check the box and either print it, delete it, or forward it on via e-mail.
For outgoing faxes, they create an e-mail with an attachment (Word, Excel, or PDF format), add the phone number to a custom header, and mail it to the hylafax address. The server converts it to a TIFF and sends it on as a regular fax. All sites have a fancy Toshiba e650 photcopier/printer/scanner that includes scan-to-email features. And we've created custom templates to automate most of this on the photocopier.
For internal (within the district) "faxes", we have the aforementioned scan-to-email feature on the Toshiba copiers. And a central LDAP directory with everyone's name in it. All they do is type in the name of the person they want to send the document to, hit scan, and they're done.
Total cost of the software and line installation is ~$6,000 CDN. We're going to test it until December. If everything works according to plan, we can start cancelling fax lines at all the schools, which will save us ~$1,000 per line per year (with 50 sites).
The nicest thing about Hylafax is no yearly licensing fees. Pay for it once up front, the software is yours forever. Sure, if you want newer versions, you have to pay again, but you only pay once per version.
The fork you speak of is OPALS-NA, which adds a *much* nicer user interface to Koha. There's also a newer version known as zOPALS that uses z39.50 servers/protocol for most import, search, and export duties. zOPALS also handles union catalogues across sites.
We've been testing OPALS-NA at 6 sites (4 elementary schools, 1 secondary school, and 1 central library cataloguing site) for the past year. We've also been testing zOPALS for the past three months or so. Everyone is very impressed with it so far.
OPALS-NA/zOPALS isn't free, and it's not fully open-source (you get the source and can play with it however you like, but you aren't allowed to share it with anyone).
And it's Canadian, written/managed by Bibliofiche in Montreal, Quebec.:) Can't get much better than that.:)
They've added links and integration with their CERF product, which link search results to relevant (and human checked) websites, and Knowledge Suite product, which is an online course outline, teaching plan creation/sharing site.
That's the combo we're using to filter all messages for a school district (1600 staff accounts, roughly 8000 student accounts, approx 15 domains). 1 server handles all incoming and outgoing mail, and then it sends the messages off to appropriate mail server. Blocks approx 30,000 viruses and 120,000 spam messages each month. Server is a dual-Athlon-MP 2200+ with 3 GB RAM and 400 GB HD in RAID5 running FreeBSD 5.
Configuration was simple, administration is even simpler.
You're not reading the same messages as everybody else, then.:)
The OpenBSD people are asking for documentation to the hardware that is already out on the market. That people have already purchased.
The Adaptec guy is telling them to wait for a future release, that will include a GUI tool, an SDK for that GUI tool, and a new set of firmware that will need to be loaded into existing hardware (or for new hardware).
Not the same thing at all. The OpenBSD people don't want a GUI tool. They don't want a new firmware. All they want is documentation on how to access the hardware they already have.
They don't want support. They don't want firmware. They don't want new hardware. All they want is documentation to the existing hardware so that they can write their own drivers, their own management tools, and can provide their users with support.
Get a better tar.:) For instance, the bsdtar from FreeBSD can handle cpio, pax, and several different tar formats (for creating and extracting).
Or, use pax. It's got a much nicer syntax than cpio, and can also handle cpio, pax, and tar formats.
We used to use a horrible combination of cpio, bzip2, and split to image our servers. Was a royal pain to use, especially if you only wanted 1 or 2 files out of the backup. Switched to pax on Linux and bsdtar on *BSD, and everything is just hunky-dorry.
Not completely cross-platform if you want free Windows support (although PowerArchiver does handle these tarballs), but it works for our uses.
They do blink. But, it's more a factor of the quality of the fixture and power coming into the fixture.
For instance, I've got a bunch of 13W compact fluorescent bulbs. When used in the roof fixtures of our place, there's no blinking, and they reach full power very quickly. But, when used in my ancient table lamp (had it since i was 5-ish), every fourth or fifth time I turn it on, the bulb just flashes and flashes and flashes. Turning it off and on again will fix things (I've since switched back to an incandescent in that lamp).
Pentium-M performance relative to Pentium-4 has nothing to do with power-saving features. It has everything to do with the modified P6 core (same core the Pentium-3 uses), better branch prediction, and much higher instructions-per-clock. These all tie together to let the Pentium-M do more work in fewer cycles than the Pentium-4, which leads to better performance at slower speeds.
[quote]You see, Microsoft prides itself upon backward compatibility. And they're damn good at it too. I can still run programs compiled for Win95/3.1 on my XP box. No other OS today will run a program designed for an Operating System 10 years old while still having the features one would expect from a modern operating system.[/quote] FreeBSD 5.x has the ability to run binaries compiled on FreeBSD 1.x, 2.x, 3.x, and 4.x. That goes back more than 13 years, all the way to the beginnings of the OS. Try running a Windows 1.x binary on even Windows 3.x, let alone on Windows 9x or XP.:)
MS is good at *some* kinds of backward compatibility, but not all kinds. For example, try saving a document in Word 97 format using Word 2003, and then opening that document in Word 97, Word 2000, Word 2002, and Word 2003. It won't look the same in all of those programs, and not all of them will open the file the first time.
We had problems running MS Works 3.0 (16-bit Windows 3.x program) (only program from MS that I absolutely loved using) on Windows 95. It would barely run on Windows 98. And I've yet to try to install it on 2K or XP.
Yes, XP includes a lot of good compatibility features (like Windows-On-Windows for 16-bit support), but it's not the end-all and be-all of backward compatibility.
Intel needs to go back to the drawing board and re-design their SMP implementation. There's nothing worse than adding CPUs to a system, only to reduce the amount of memory throughput available to each CPU.
With Intel's SMP setup, total system memory bandwidth is a constant, regardless of the number of CPUs in the system. As you add CPUs, the amount of bandwidth available per CPU decreases.
Throw a couple of CPU cores into each CPU socket and you lower the available memory bandwidth to each core even more.
With AMD's SMP setup, total memory bandwidth per CPU is a constant. As you add CPUs to a system, though, total system memory bandwidth increases.
Not sure how this would work with multiple cores in on CPU, though. Would there be a separate memory controller per CPU socket, or per CPU core??
Firewire devices do not need a central compute-node to handle I/O transfers. They just pass the data directly between the two devices. Firewire is a bus where point-to-point transfers take place (similar to SCSI), whereas USB is a spoke-and-hub bus that requires all data pass through the main CPU. (Or something along those lines.)
This is why 1394a (400 Mbps) feels faster than USB 2.0 (480 Mbps).
A couple weeks after the release of FreeBSD 5.2.1, the GENERIC kernel was changed to compile an SMP kernel, and SMP support was controlled via a sysctl.
Just before the release of FreeBSD 5.3, GENERIC was changed to create a UP kernel, as that is the most common install. However, you can compile an SMP kernel and run it just fine on a UP system. You will lose a bit of system performance, but it will run.
Cache coherance, cache access, and bus contention are only problems for Intel. AMD solved most of these with the Athlon-MP and HyperTransport, and solved the reset with the Opteron's integrated memory controller.
In AMD SMP systems, each CPU has its own separate link to RAM and peripherals. Each CPU also has a link to each other CPU. If CPU A needs something in CPU B's cache, it just asks CPU A to send it that data across the inter-CPU link.
As you add CPUs in an Opteron server, you actually increase the RAM/system bandwidth. Compare that to a Xeon system where adding CPUs reduces the bandwidth available to each CPU (system/RAM bandwidth is constant).
There's a beautiful set of articles over at Ars Technica describing the SMP abilities of the Athoon, the Opteron, and the Xeon. It's amazing Intel has been able to sell any 8-way systems.
For those tracking the release, the RELENG_5_3 tag for cvsup is working. Right now, there's not much difference in the source trees for RELENG_5 and RELENG_5_3, and changes could still be made to the RELENG_5_3 tree, so it's not the official release bits just yet.
But, you can start updating your cvsup supfiles in anticipation.:)
Correct. And the SMP options have been removed from GENERIC for 5.3-RELEASE. This means that a default install of FreeBSD 5.3 will include a non-SMP kernel. They will be including docs for creating an SMP kernel after installation, and are investigating a method for shipping both a UP and SMP kernel, giving the user a choice of which to install. They don't expect that to come through until 5.4, though.
Here's the Head's Up message posted to the -current mailing list.
One of the nicer things about the FreeBSD Documentation Project is that everything is available both online and offline. All the man pages for every release of FreeBSD (going all the back to 1.0), along with OpenBSD, NetBSD, and several Linux distros, are available at http://www.freebsd.org/cgi/man.cgi
And, if you selected the docs distribution during the install, you'll find all the articles, books, and papers under/usr/share/doc, including the Handbook and the Porter's Handbook. If you didn't install the docs during the initial install, they can be fetched (and/or updated) using cvsup. There's a samples docs supfile in/usr/share/examples/cvsup. Just be sure to set DOCS_LANG in/etc/make.conf to the language you want, otherwise you'll get every language availables.:)
Having all the documentation available offline is a boon for those days when you break the network.:)
Read/usr/src/UPDATING included with the latest BETAs, and the HEADS UP thread about it on the -current mailing list. Everything you need to know is in those two places.
Windows NT did not have a text-mode either (other than the anemic recovery console). You either booted into the GUI or you didn't boot at all. It came with two different command interpreters/shells, though: command.com (DOS emulator) and cmd.exe. But you couldn't really use the command prompt for anything, and remotely controlling another station/server was a real pain.
The MacOS didn't get a commandline interface until MacOS X came along, and it didn't really need it. It came with AppleScript built in, making it very easy to script things. I don't know if had remote login or remote screen viewing or anything like VNC/RDP back then or not, but it didn't really need it, either.
Not having a commandline is only a problem if the GUI is structured in such a way that it can't be scripted, or accessed remotely in an efficient manner. If you make everything scriptable or accessable remotely, in a secure manner, then it doesn't really matter if it's using a text-mode boot, a GUI boot, or a CLI in a GUI.
Read through the archives of the kernel mailing list archive. These kinds of questions pop up now and then and Matt and co have responded to them in length over the past month or so. Very informative, and not too technical.
Slashdot Mirror
We're using OpenOffice.org in all of our elementary schools (K-7) with great success. Some teachers are using KWrite with the younger (K-3) students. Depending on the teachers knowledge, the students are doing some amazing things with OpenOffice.org (pamphlets, animated slideshows, newsletters, etc).
:(
The secondary schools are a much harder sell due to teacher reluctance. Too many teachers are hung up on the "industry uses Office, therefore we must teach Office" mantra, which is horse shit.
We should be teaching the students how to use proper formatting, what the different styles of letters and memos are, how to layout a spreadsheet and use formulas, how to do proper page layout with mixed text and images, etc. Use one or two or three different office suites, to show you know the skills and not just where the options are in the menu of that one app.
It's understandable for the teachers that have a lot of teaching resources and course plans already tailored to a specific app. But that should not prevent them from installing other office suites, and slowly making them ofice suite agnostic. Of course, since very few teachers in this district communicate with others or share lesson plans, this will never happen.
Schools should *NOT* be teaching specific applications. Courses should not be geared toward one specific version of an application.
Instead, schools should be teaching skills that can be applied to all similar programs.
For instance, there should not be an "MS Word" course; there should be a "Wordprocessing" course. Students should be taught what the different formatting options are, when to use them, what the different letter and memo formats are, how to insert images and make text flow around them, etc. In a perfect world, they would use more than one office suite in the course, to see how the different applications do the same thing.
Public schools are *NOT* trades schools, they are *NOT* training schools for companies. The point of school is *NOT* to get a job. The point is to learn, to expand your intellect. What you do with that knowledge is up to you. But school should not be a training ground for specific jobs.
It's the same with Office. Unless you have the Office fast startup thingy loading at login, it takes a long time to load Word or Excel or even Outlook. Double-clicking on a document to auto-load it in Word takes even longer.
Loading the fast startup thingy for OO.org or Office makes things a lot faster, at the cost of quite a bit of RAM. It's a trade-off, and can either be very useful (need to access documents right after logging in) or a pain (losing all that RAM when you don't need to edit docs).
Sign a piece of paper. Scan that piece of paper into a JPEG or PNG. Save that to a file. Then just insert that into your documents.
:)
Saves time on printing (already signed), and saves money on faxes.
Just be sure to keep the image file secure.
We haven't implemented it just yet (waiting for the local telco to install the needed incoming/outgoing lines to the school board office), but we're going with Hylafax as well.
For incoming faxes, we have 50 fax numbers mapped to 6 incoming DID lines, connected to some fancy fax device connect to a Hylafax server. That converts the incoming fax to an e-mail with an attached PDF, and drops it into a site e-mail box. Secretaries at each site check the box and either print it, delete it, or forward it on via e-mail.
For outgoing faxes, they create an e-mail with an attachment (Word, Excel, or PDF format), add the phone number to a custom header, and mail it to the hylafax address. The server converts it to a TIFF and sends it on as a regular fax. All sites have a fancy Toshiba e650 photcopier/printer/scanner that includes scan-to-email features. And we've created custom templates to automate most of this on the photocopier.
For internal (within the district) "faxes", we have the aforementioned scan-to-email feature on the Toshiba copiers. And a central LDAP directory with everyone's name in it. All they do is type in the name of the person they want to send the document to, hit scan, and they're done.
Total cost of the software and line installation is ~$6,000 CDN. We're going to test it until December. If everything works according to plan, we can start cancelling fax lines at all the schools, which will save us ~$1,000 per line per year (with 50 sites).
The nicest thing about Hylafax is no yearly licensing fees. Pay for it once up front, the software is yours forever. Sure, if you want newer versions, you have to pay again, but you only pay once per version.
The fork you speak of is OPALS-NA, which adds a *much* nicer user interface to Koha. There's also a newer version known as zOPALS that uses z39.50 servers/protocol for most import, search, and export duties. zOPALS also handles union catalogues across sites.
:) Can't get much better than that. :)
We've been testing OPALS-NA at 6 sites (4 elementary schools, 1 secondary school, and 1 central library cataloguing site) for the past year. We've also been testing zOPALS for the past three months or so. Everyone is very impressed with it so far.
OPALS-NA/zOPALS isn't free, and it's not fully open-source (you get the source and can play with it however you like, but you aren't allowed to share it with anyone).
And it's Canadian, written/managed by Bibliofiche in Montreal, Quebec.
They've added links and integration with their CERF product, which link search results to relevant (and human checked) websites, and Knowledge Suite product, which is an online course outline, teaching plan creation/sharing site.
That's the combo we're using to filter all messages for a school district (1600 staff accounts, roughly 8000 student accounts, approx 15 domains). 1 server handles all incoming and outgoing mail, and then it sends the messages off to appropriate mail server. Blocks approx 30,000 viruses and 120,000 spam messages each month. Server is a dual-Athlon-MP 2200+ with 3 GB RAM and 400 GB HD in RAID5 running FreeBSD 5.
Configuration was simple, administration is even simpler.
Looking at possibly adding dspam into the mix.
You're not reading the same messages as everybody else, then. :)
The OpenBSD people are asking for documentation to the hardware that is already out on the market. That people have already purchased.
The Adaptec guy is telling them to wait for a future release, that will include a GUI tool, an SDK for that GUI tool, and a new set of firmware that will need to be loaded into existing hardware (or for new hardware).
Not the same thing at all. The OpenBSD people don't want a GUI tool. They don't want a new firmware. All they want is documentation on how to access the hardware they already have.
They don't want support. They don't want firmware. They don't want new hardware. All they want is documentation to the existing hardware so that they can write their own drivers, their own management tools, and can provide their users with support.
Get a better tar. :) For instance, the bsdtar from FreeBSD can handle cpio, pax, and several different tar formats (for creating and extracting).
Or, use pax. It's got a much nicer syntax than cpio, and can also handle cpio, pax, and tar formats.
We used to use a horrible combination of cpio, bzip2, and split to image our servers. Was a royal pain to use, especially if you only wanted 1 or 2 files out of the backup. Switched to pax on Linux and bsdtar on *BSD, and everything is just hunky-dorry.
Not completely cross-platform if you want free Windows support (although PowerArchiver does handle these tarballs), but it works for our uses.
AMD isn't working on HyperThreading. They are working on multi-core CPUs. Very difference beasts.
They do blink. But, it's more a factor of the quality of the fixture and power coming into the fixture.
For instance, I've got a bunch of 13W compact fluorescent bulbs. When used in the roof fixtures of our place, there's no blinking, and they reach full power very quickly. But, when used in my ancient table lamp (had it since i was 5-ish), every fourth or fifth time I turn it on, the bulb just flashes and flashes and flashes. Turning it off and on again will fix things (I've since switched back to an incandescent in that lamp).
Pentium-M performance relative to Pentium-4 has nothing to do with power-saving features. It has everything to do with the modified P6 core (same core the Pentium-3 uses), better branch prediction, and much higher instructions-per-clock. These all tie together to let the Pentium-M do more work in fewer cycles than the Pentium-4, which leads to better performance at slower speeds.
[quote]You see, Microsoft prides itself upon backward compatibility. And they're damn good at it too. I can still run programs compiled for Win95/3.1 on my XP box. No other OS today will run a program designed for an Operating System 10 years old while still having the features one would expect from a modern operating system.[/quote] :)
FreeBSD 5.x has the ability to run binaries compiled on FreeBSD 1.x, 2.x, 3.x, and 4.x. That goes back more than 13 years, all the way to the beginnings of the OS. Try running a Windows 1.x binary on even Windows 3.x, let alone on Windows 9x or XP.
MS is good at *some* kinds of backward compatibility, but not all kinds. For example, try saving a document in Word 97 format using Word 2003, and then opening that document in Word 97, Word 2000, Word 2002, and Word 2003. It won't look the same in all of those programs, and not all of them will open the file the first time.
We had problems running MS Works 3.0 (16-bit Windows 3.x program) (only program from MS that I absolutely loved using) on Windows 95. It would barely run on Windows 98. And I've yet to try to install it on 2K or XP.
Yes, XP includes a lot of good compatibility features (like Windows-On-Windows for 16-bit support), but it's not the end-all and be-all of backward compatibility.
And Opera had non-tabbed MDI support before that (3.0 was the first I tried). I actually preferred the MDI approach for some browsing scenarios.
And I hated tabbed browsing for a long time. Now it's something I'm used to, but still not something I think of as a "killer feature".
Intel needs to go back to the drawing board and re-design their SMP implementation. There's nothing worse than adding CPUs to a system, only to reduce the amount of memory throughput available to each CPU.
With Intel's SMP setup, total system memory bandwidth is a constant, regardless of the number of CPUs in the system. As you add CPUs, the amount of bandwidth available per CPU decreases.
Throw a couple of CPU cores into each CPU socket and you lower the available memory bandwidth to each core even more.
With AMD's SMP setup, total memory bandwidth per CPU is a constant. As you add CPUs to a system, though, total system memory bandwidth increases.
Not sure how this would work with multiple cores in on CPU, though. Would there be a separate memory controller per CPU socket, or per CPU core??
You didn't mention which version of FreeBSD, just that you tried it recently (which, to me, implies 5.x, as that's the most recent version).
Yes, in FreeBSD 4.x, you must run a non-SMP kernel on uni-processor systems.
Yes, this has changed since the release of FreeBSD 5.3.
Firewire devices do not need a central compute-node to handle I/O transfers. They just pass the data directly between the two devices. Firewire is a bus where point-to-point transfers take place (similar to SCSI), whereas USB is a spoke-and-hub bus that requires all data pass through the main CPU. (Or something along those lines.)
This is why 1394a (400 Mbps) feels faster than USB 2.0 (480 Mbps).
Nope, your info is very out-of-date.
A couple weeks after the release of FreeBSD 5.2.1, the GENERIC kernel was changed to compile an SMP kernel, and SMP support was controlled via a sysctl.
Just before the release of FreeBSD 5.3, GENERIC was changed to create a UP kernel, as that is the most common install. However, you can compile an SMP kernel and run it just fine on a UP system. You will lose a bit of system performance, but it will run.
Cache coherance, cache access, and bus contention are only problems for Intel. AMD solved most of these with the Athlon-MP and HyperTransport, and solved the reset with the Opteron's integrated memory controller.
In AMD SMP systems, each CPU has its own separate link to RAM and peripherals. Each CPU also has a link to each other CPU. If CPU A needs something in CPU B's cache, it just asks CPU A to send it that data across the inter-CPU link.
As you add CPUs in an Opteron server, you actually increase the RAM/system bandwidth. Compare that to a Xeon system where adding CPUs reduces the bandwidth available to each CPU (system/RAM bandwidth is constant).
There's a beautiful set of articles over at Ars Technica describing the SMP abilities of the Athoon, the Opteron, and the Xeon. It's amazing Intel has been able to sell any 8-way systems.
For those tracking the release, the RELENG_5_3 tag for cvsup is working. Right now, there's not much difference in the source trees for RELENG_5 and RELENG_5_3, and changes could still be made to the RELENG_5_3 tree, so it's not the official release bits just yet.
:)
But, you can start updating your cvsup supfiles in anticipation.
Correct. And the SMP options have been removed from GENERIC for 5.3-RELEASE. This means that a default install of FreeBSD 5.3 will include a non-SMP kernel. They will be including docs for creating an SMP kernel after installation, and are investigating a method for shipping both a UP and SMP kernel, giving the user a choice of which to install. They don't expect that to come through until 5.4, though.
Here's the Head's Up message posted to the -current mailing list.
One of the nicer things about the FreeBSD Documentation Project is that everything is available both online and offline. All the man pages for every release of FreeBSD (going all the back to 1.0), along with OpenBSD, NetBSD, and several Linux distros, are available at http://www.freebsd.org/cgi/man.cgi
/usr/share/doc, including the Handbook and the Porter's Handbook. If you didn't install the docs during the initial install, they can be fetched (and/or updated) using cvsup. There's a samples docs supfile in /usr/share/examples/cvsup. Just be sure to set DOCS_LANG in /etc/make.conf to the language you want, otherwise you'll get every language availables. :)
:)
And, if you selected the docs distribution during the install, you'll find all the articles, books, and papers under
Having all the documentation available offline is a boon for those days when you break the network.
Read /usr/src/UPDATING included with the latest BETAs, and the HEADS UP thread about it on the -current mailing list. Everything you need to know is in those two places.
Windows NT did not have a text-mode either (other than the anemic recovery console). You either booted into the GUI or you didn't boot at all. It came with two different command interpreters/shells, though: command.com (DOS emulator) and cmd.exe. But you couldn't really use the command prompt for anything, and remotely controlling another station/server was a real pain.
The MacOS didn't get a commandline interface until MacOS X came along, and it didn't really need it. It came with AppleScript built in, making it very easy to script things. I don't know if had remote login or remote screen viewing or anything like VNC/RDP back then or not, but it didn't really need it, either.
Not having a commandline is only a problem if the GUI is structured in such a way that it can't be scripted, or accessed remotely in an efficient manner. If you make everything scriptable or accessable remotely, in a secure manner, then it doesn't really matter if it's using a text-mode boot, a GUI boot, or a CLI in a GUI.
Read through the archives of the kernel mailing list archive. These kinds of questions pop up now and then and Matt and co have responded to them in length over the past month or so. Very informative, and not too technical.