* Forgetting to bring something for show and tell in Grade I would mean you were ordered to go home and get it...unescorted..even if you lived a couple kilometres away or had to cross major throughfares. The parents wouldn't be notified of this.
* One teacher would throw objects at her students' heads if they were talking when she didn't want them to (chalk, etc). When my girfriend caught flying chalk coming toward her head one day and threw it back she was sent home and told not to come back the next day.
* Locking children in broom closets was a choice method of discipline. Parents were not notified of behavioural problems that justified such a punishment, nor were they asked if it was appropriate to discipline their child that way.
* Yelling and screaming tantrums--by the teachers--was common in some classes.
While lack of accountability is a serious problem in Quebec's public school system (is it not elsewhere ?), I have absolutely no doubt that any of the examples you provided above would be ground for severe reprimands against the teacher, especially the first and third which would definitely be enough for getting the teacher fired. And I am not talking about third-hands experience here : I have been schooled by the public Quebec education system, know many elementary and secondary grade teachers and have kids in elementary.
Motherboard themselves are mostly supported, but some components on newer chipset are often broken or not working at all in Linux at first. For example, support for the JMicron JMB361 disk controller, that is often coupled with Intel 965 to provide PATA, just got into the mainline kernel recently and still have to get picked up by most distro. Marvell Ethernet where notoriously not working with Linux for a long while (this is mostly fixed now). The NForce2 Ethernet, when it came out a long time ago, was notoriously not Linux-friendly for a few months before it got reverse-engineered and the forcedeth driver came out. Yadda, yadda...
Open Source does not mean Free or free. You can release the source to your customers without giving your customers the right to redistribute it or their changes.
Echo will live in your nightmares and make you fail. get real digium cards, nothing else.
Digium hardware is far from echo-proof. Actually, I had a pretty bad echo problem in my last PABX job, using brand name Digium analog line-card (TDM400P). Asterisk software echo cancellation is a waste of time. Digium now have hardware echo cancellation on some card. But so does Sangoma and it is reportedly much better than Digium.
Hardware Layer - People care about phones, they may not mention it but they do. For a school where emergancy services are key I would look for a ten year solution. Water cooling, oversized tyan system with raid->lvm->xen->ntp,bind,asterisk,www,tftp,etc.....
Excuse me... are you seriously suggesting running a phone system on a water-cooled rig ? This is not your LAN party boxen, pal. Why not buy a good mid-range server from a top-tier manufacturer (IBM, HP, Dell, Sun, whatever), along with a 4 hours onsite extended warranty ?
And what exactly does Xen provide in this setup ? What is wrong with running on the bare metal ? Xen is still a pretty young technology, I would not trust mission-critical system to it. But that's just me.
Maintenance is considered tedious by most programmers (for good reasons), and thus most would rather work on new features than on fixing existing ones. But please, ho please, could the Mozilla gang just go through their Bugzilla and have a look at lingering bugs and enhancement request ? There are bugs that have been assigned for *years* that are still lingering, with the devs just not providing any feedback about potential resolution. Either close them as WONTFIX, so people will know that it will not get worked upon anymore, or actually assign some ressource to it and have them fixed, once and for all. Or mark them as FIXED, if they happened to be somehow.
Beside that, trimming the memory footprint would nice, as would be better standard support and better locale handling. Firefox (actually, Mozilla in general) is a pretty mature project now, so I would rather see incremental improvements in stability, performance and standard/locale support than any new whizbang feature.
Unfortunately, if you insist that every program stand alone, it doesn't work terribly well. Shared libraries go out the window and you use a lot more memory and even a lot more disk. Things start up slowly. Libraries that have compatibility tweaks for a specific platform aren't the ones used, you use your own ones and those break. And so on.
For most users there's not much of a reason to use package management for a program like Firefox.
Er, no. At least, it depend on how you define "most users". Home users and isolated desktops can probably rely on the Firefox auto-updater, but any significant deployment benefit from centralized package management (imagine the mess of a lab in a University that rely on Firefox auto-updater to be kept up-to-date).
Personnally, I do not care about the latest and greatest Firefox release. I have no time to chase the latest and manually upgrade, and their auto-updater is redundant with my Linux distribution package manager. I pretty much only update Firefox when I update my Linux distribution to a new release. 1.0.7 in Debian is quite usable and do everything I need, thank you. Why should'nt I be able to continue to use it if the Debian people are willing to maintain it ?
I don't see anything wrong with asking someone who forks your codebase to use a different name to avoid confusion. What's the problem with that?
Technically speaking, any package in a Linux distribution is a fork. You always have to re-arrange file layout, fix bugs that the upstream project do not care about (ie security issue in version of Firefox that Mozilla.com abandonned) and generally adapt to how things are being done in your distro. You may disagree with that, but this is what a Linux distribution is about : making disparate FOSS into a cohesive whole. Considering that, should all Linux distribution systematically rename all the software they package ?
The best example of the absurdity of that position is not Firefox, but the Linux kernel itself. It's pretty much a given that most Linux distribution heavily patch the kernel. It's actually expected to have bug fixes and security patch backported, as responsible sysadmins do not update their kernels willy-nilly. And oftentime, Linux distribution often include out-of-tree features (drivers, etc) that are useful their users. Should the Linux kernel be renamed in distribution that modify it ? If yes, then should we continue to call these "Linux" distribution ?
The serial Elo touchscreen controller I had the opportunity to use worked fine (although calibration require the use of a DOS software... pfewww !).
However, the USB version have driver issue. Elo provide binary drivers for the USB controllers for a few outdated distro (RedHat 9, anybody ?). They do provide source for the USB driver, but it does not have any copyright info (thus, I have no idea if I can distribute it to my client), it contain object code, it is poorly documented (.doc ? WTF ?) and I could not get it to compile.
Personnally, I would avoid using the USB Elo controller with Linux. If you need USB, try to find another touch-screen maker that is more Linux-friendly.
Either that, or they are just building the infrastructure to peer with last tier ISP, and thus evad the carrier tax by bypassing them altogether. From there on, actually providing the carrier service is just a very small step away...
If people had the choice between a dozen different broadband ISPs each with some reasonable slice of the market, this wouldn't be an issue.
That's a pretty big "if". How would you ensure people actually get the choice at all ?
To me, the outcome of an all-out deregulation appear quite obvious : global monopolies cherry-picking the most lucrative market and catering solely to the lowest common denominator, while breaking interoperability to keep out smaller contenders. You may say that I smoke crack, but we currently have a telecomm system that mostly work despite being heavily regulated. The burden of proof is on the total-deregulation crowd, who wish to throw the baby with the bathwater. I do not pretend that the current regulation framework is perfect, but it would be much easier globally to fix it than to clean the mess of a complete deregulation IMHO. *erm*California power deregulation*erm*
Incidentally, I currently have the choice of about half-a-dozen broadband ISP in my heavily regulated area, and I certainly benefit a lot from the price war going on. I never paid any less for telecomm than in the past year. So there.
I have this problem too. I wish I could get my news fix somewhere else, but/. is still my home page. NewsForge is almost good enough, but the volume is a bit on the slow side, and there is not enough discussion going on about the article (althought it is getting better). Digg is... well, Digg. Technocrat.net have too much science stuff; cool, but not what I am looking for. Ars Technica have too little stories about Linux and FOSS. Blogs are, mostly, boring. What else ?
- Make sure you have a PTR record correctly set to your hostname so that reverse lookup work. Whoever have been assigned the block from which your IP is taken (most likely, your ISP) is the one to contact for that.
- Make sure the HELO/EHLO greeting of your MTA match the FQDN in the PTR record for the IP your mail appear to be coming from. In other words, make sure the hostname is set correctly on your mail server.
Sorry for the elitism, but if you don't quite understand the above, maybe you should not be running a mail server in the first place...
It's based on Fedora Core 3, just like the rest of the RHEL 4.
I hate to be the Red Hat shill, but damn, there's a lot of uninformed opinions about Red Hat going on around here.
Re:distro fragmentation
on
Ubuntu Hacks
·
· Score: 2, Insightful
however, most "hacks", such as installing LAMP, tuning perforamnce, file sharing, etc., should be mostly the same for all linux distros.
Hummmm... no. SysV init management, configuration files localisation (layout of/etc), default configuration of various subsystem, etc vary greatly between distro. Example : Apache configuration. In RedHat and friends, the default config is pretty vanilla, and reside in/etc/httpd. In Debian, it's in/etc/apache2, and the way virtual hosts configuration is managed (sites-available/sites-enabled symlinks) is pretty unique (and astucious).
Some people find the differences irritating and call that "fragmentation". Personnally, I think they are mostly superficial, and become clear once you know the fundation and rational behind the distro design. You need to know your tools, anyway.
Re:distro fragmentation
on
Ubuntu Hacks
·
· Score: 2, Insightful
In my experiences, one of the main factors tends to be package managment. Does the distro use.deb or.rpm?
It does'nt make any difference..deb and RPM are just package format; a way to carry files, meta-data and (de)installation scripts. Technically, they are both pretty close in term of functionnalities. The real difference between distro packaging is two-folds : high-level package manager (apt, yum, urpm, yast, emerge, etc), and quality of packaging.
The two main high-level package manager are apt and yum. Yum is serviceable, but slow (so is YaST). Apt is very fast, but quirky at times. I have a love-hate relationship with both. Functionnally, they are pretty similar.
Where Debian-derived usually spank the competition is quality of packaging. It's hard to beat the result of the Debian packaging policy and thorough QA. Compared to Debian, RedHat feel slapped together by amateur. And don't mention Mandriva, I will puke.
So in the end, RPM or.deb, it does'nt make any difference. Even the choice of high-level package management tools is really just a matter of taste at this point. What really make or break a distro is the amount and quality of work that have gone into brewing the distro.
The way things are going in three to five years nobody will be able to charge for a database. Look how fast mysql and postgres are gaining features.
Well, many organisation have a lot of ressources invested in Oracle and have large application built around Oracle-specific features. Oracle also have a lot of mindshare among DBA. They are not going to switch overnight. They will continue to pay Oracle for support and upgrade for along time to come, because it's cheaper and safer to do so.
I predict a very slow but steady decline for the big database vendors. It might take a decade or two before OSS database got a significant portion of the enterprise market. In the meantime, Oracle and cie will try to diversify into related markets : ERP, dev tools, etc.
Ho wait, that's already happening ! Too bad these segments are also being commoditized...
Slashdot Mirror
While lack of accountability is a serious problem in Quebec's public school system (is it not elsewhere ?), I have absolutely no doubt that any of the examples you provided above would be ground for severe reprimands against the teacher, especially the first and third which would definitely be enough for getting the teacher fired. And I am not talking about third-hands experience here : I have been schooled by the public Quebec education system, know many elementary and secondary grade teachers and have kids in elementary.
Motherboard themselves are mostly supported, but some components on newer chipset are often broken or not working at all in Linux at first. For example, support for the JMicron JMB361 disk controller, that is often coupled with Intel 965 to provide PATA, just got into the mainline kernel recently and still have to get picked up by most distro. Marvell Ethernet where notoriously not working with Linux for a long while (this is mostly fixed now). The NForce2 Ethernet, when it came out a long time ago, was notoriously not Linux-friendly for a few months before it got reverse-engineered and the forcedeth driver came out. Yadda, yadda ...
Only if you redefine the meaning of Open Source
How well is it supported in Linux ? I don't care about the new glitz if I cannot make use of it.
Digium hardware is far from echo-proof. Actually, I had a pretty bad echo problem in my last PABX job, using brand name Digium analog line-card (TDM400P). Asterisk software echo cancellation is a waste of time. Digium now have hardware echo cancellation on some card. But so does Sangoma and it is reportedly much better than Digium.
Excuse me ... are you seriously suggesting running a phone system on a water-cooled rig ? This is not your LAN party boxen, pal. Why not buy a good mid-range server from a top-tier manufacturer (IBM, HP, Dell, Sun, whatever), along with a 4 hours onsite extended warranty ?
And what exactly does Xen provide in this setup ? What is wrong with running on the bare metal ? Xen is still a pretty young technology, I would not trust mission-critical system to it. But that's just me.
Maywest ? You surely mean Joe Louis, right ?
It already is.
Maintenance is considered tedious by most programmers (for good reasons), and thus most would rather work on new features than on fixing existing ones. But please, ho please, could the Mozilla gang just go through their Bugzilla and have a look at lingering bugs and enhancement request ? There are bugs that have been assigned for *years* that are still lingering, with the devs just not providing any feedback about potential resolution. Either close them as WONTFIX, so people will know that it will not get worked upon anymore, or actually assign some ressource to it and have them fixed, once and for all. Or mark them as FIXED, if they happened to be somehow.
Beside that, trimming the memory footprint would nice, as would be better standard support and better locale handling. Firefox (actually, Mozilla in general) is a pretty mature project now, so I would rather see incremental improvements in stability, performance and standard/locale support than any new whizbang feature.
My, my! That remind me of some other OS ...
Er, no. At least, it depend on how you define "most users". Home users and isolated desktops can probably rely on the Firefox auto-updater, but any significant deployment benefit from centralized package management (imagine the mess of a lab in a University that rely on Firefox auto-updater to be kept up-to-date).
Personnally, I do not care about the latest and greatest Firefox release. I have no time to chase the latest and manually upgrade, and their auto-updater is redundant with my Linux distribution package manager. I pretty much only update Firefox when I update my Linux distribution to a new release. 1.0.7 in Debian is quite usable and do everything I need, thank you. Why should'nt I be able to continue to use it if the Debian people are willing to maintain it ?
Technically speaking, any package in a Linux distribution is a fork. You always have to re-arrange file layout, fix bugs that the upstream project do not care about (ie security issue in version of Firefox that Mozilla.com abandonned) and generally adapt to how things are being done in your distro. You may disagree with that, but this is what a Linux distribution is about : making disparate FOSS into a cohesive whole. Considering that, should all Linux distribution systematically rename all the software they package ?
The best example of the absurdity of that position is not Firefox, but the Linux kernel itself. It's pretty much a given that most Linux distribution heavily patch the kernel. It's actually expected to have bug fixes and security patch backported, as responsible sysadmins do not update their kernels willy-nilly. And oftentime, Linux distribution often include out-of-tree features (drivers, etc) that are useful their users. Should the Linux kernel be renamed in distribution that modify it ? If yes, then should we continue to call these "Linux" distribution ?
The serial Elo touchscreen controller I had the opportunity to use worked fine (although calibration require the use of a DOS software ... pfewww !).
However, the USB version have driver issue. Elo provide binary drivers for the USB controllers for a few outdated distro (RedHat 9, anybody ?). They do provide source for the USB driver, but it does not have any copyright info (thus, I have no idea if I can distribute it to my client), it contain object code, it is poorly documented (.doc ? WTF ?) and I could not get it to compile.
Personnally, I would avoid using the USB Elo controller with Linux. If you need USB, try to find another touch-screen maker that is more Linux-friendly.
In Synaptic : Settings menu, Repositories, click the Add button.
Or was it because of the cost, buggyness and lack of development tools ?
Either that, or they are just building the infrastructure to peer with last tier ISP, and thus evad the carrier tax by bypassing them altogether. From there on, actually providing the carrier service is just a very small step away ...
That's a pretty big "if". How would you ensure people actually get the choice at all ?
To me, the outcome of an all-out deregulation appear quite obvious : global monopolies cherry-picking the most lucrative market and catering solely to the lowest common denominator, while breaking interoperability to keep out smaller contenders. You may say that I smoke crack, but we currently have a telecomm system that mostly work despite being heavily regulated. The burden of proof is on the total-deregulation crowd, who wish to throw the baby with the bathwater. I do not pretend that the current regulation framework is perfect, but it would be much easier globally to fix it than to clean the mess of a complete deregulation IMHO. *erm*California power deregulation*erm*
Incidentally, I currently have the choice of about half-a-dozen broadband ISP in my heavily regulated area, and I certainly benefit a lot from the price war going on. I never paid any less for telecomm than in the past year. So there.
I have this problem too. I wish I could get my news fix somewhere else, but /. is still my home page. NewsForge is almost good enough, but the volume is a bit on the slow side, and there is not enough discussion going on about the article (althought it is getting better). Digg is ... well, Digg. Technocrat.net have too much science stuff; cool, but not what I am looking for. Ars Technica have too little stories about Linux and FOSS. Blogs are, mostly, boring. What else ?
<sarcasm>Only the market can be right !</sarcasm>
Two things :
...
- Make sure you have a PTR record correctly set to your hostname so that reverse lookup work. Whoever have been assigned the block from which your IP is taken (most likely, your ISP) is the one to contact for that.
- Make sure the HELO/EHLO greeting of your MTA match the FQDN in the PTR record for the IP your mail appear to be coming from. In other words, make sure the hostname is set correctly on your mail server.
Sorry for the elitism, but if you don't quite understand the above, maybe you should not be running a mail server in the first place
Helllllllo ?!? Red Hat already have a desktop product, and always had. Red Hat Enterprise Linux WS -> http://www.redhat.com/rhel/details/clients/
It's based on Fedora Core 3, just like the rest of the RHEL 4.
I hate to be the Red Hat shill, but damn, there's a lot of uninformed opinions about Red Hat going on around here.
Hummmm ... no. SysV init management, configuration files localisation (layout of /etc), default configuration of various subsystem, etc vary greatly between distro. Example : Apache configuration. In RedHat and friends, the default config is pretty vanilla, and reside in /etc/httpd. In Debian, it's in /etc/apache2, and the way virtual hosts configuration is managed (sites-available/sites-enabled symlinks) is pretty unique (and astucious).
Some people find the differences irritating and call that "fragmentation". Personnally, I think they are mostly superficial, and become clear once you know the fundation and rational behind the distro design. You need to know your tools, anyway.
It does'nt make any difference. .deb and RPM are just package format; a way to carry files, meta-data and (de)installation scripts. Technically, they are both pretty close in term of functionnalities. The real difference between distro packaging is two-folds : high-level package manager (apt, yum, urpm, yast, emerge, etc), and quality of packaging.
The two main high-level package manager are apt and yum. Yum is serviceable, but slow (so is YaST). Apt is very fast, but quirky at times. I have a love-hate relationship with both. Functionnally, they are pretty similar.
Where Debian-derived usually spank the competition is quality of packaging. It's hard to beat the result of the Debian packaging policy and thorough QA. Compared to Debian, RedHat feel slapped together by amateur. And don't mention Mandriva, I will puke.
So in the end, RPM or .deb, it does'nt make any difference. Even the choice of high-level package management tools is really just a matter of taste at this point. What really make or break a distro is the amount and quality of work that have gone into brewing the distro.
Well, many organisation have a lot of ressources invested in Oracle and have large application built around Oracle-specific features. Oracle also have a lot of mindshare among DBA. They are not going to switch overnight. They will continue to pay Oracle for support and upgrade for along time to come, because it's cheaper and safer to do so.
I predict a very slow but steady decline for the big database vendors. It might take a decade or two before OSS database got a significant portion of the enterprise market. In the meantime, Oracle and cie will try to diversify into related markets : ERP, dev tools, etc.
Ho wait, that's already happening ! Too bad these segments are also being commoditized ...
It might be true, but I never heard this argument outside of OS (usually, Windows) advocates. Can you quote a CIO saying "I want someone to sue !"