In redards of rebranding, did you know that for most HP laserjets (if not all) the printing mechanic is manufactured by canon? HP only provides the formater (logic, driver connected end), and the brand, the rest is done by canon.
As far as i remember this used to be the true
in the early days, where the print mechanic
was supplied by Canon and the electronis were
from HP. But this has changed since a few years
(when the LJ4 came out).
So why is this different from warranty?
If you care you are free choose a manufacturer
which gives you desired warranty periode on
your HW.
OTOH since there is only a fine line between
HW and SW these days. Should a manufacturer
be liable for software updates or are you
no longer allowed to install any software
without wiping your warranty...
Would a SW manufacturer be liable for your
HW/SW combination and thus could forbid you
any updates outside its control?
No, I'm not a KDE user but all this "illegal status" of KDE makes me
queasy. Not good for the Cause.
This is plain wrong.
Even RMS agreed that all code written by the KDE
team is compliant with the GPL.
This whole KDE license bashing is all about
some minor parts which were not originally
written by the KDE team. And it's not even
decided on if they have a point at all.
If you look at the current Linux system at a different view we might already have something along this:
1. Block devices could be plugged in and allow support of different devices. This would be the equiv. of your "Device Managers" and "Partition Managers".
2. On top of the block devices you can layer the RAID and LVM "features modules" which are then available transparently to upper layers.
3. The file system should happily sit on top of this.
Integration among those components may need some work but overall this does not seem that different. Providing a single administration point for the users is certainly something worthwile but that this is hardly something which could not be done with the current system.
Finally, LVM (any flavour) do just provide a framework. A filesystem does not become resizable on its own.
Michael
Re:Vapour or not, doesn't matter
on
Microsoft Janus
·
· Score: 1
Oh, wait, that won't be done until raw devices are in the kernel, and Linus doesn't like them. Same for other cluster-enabled RDBMSs.
Why do you need raw devices for HA?
All you need is a RAID array which is accessible access from multiple systems (one at a time). So another box can mount the fs of a failed system and take over the work. The components for this are already available (heartbeat, IP switching). All that's needed is a nice framework gluing the existing parts.
Slashdot Mirror
AFAIR the EU now requires a two years warranty
on consumer parts. So they may offer a different
warranty in the EU (or burden it on the
distributor).
As far as i remember this used to be the true in the early days, where the print mechanic was supplied by Canon and the electronis were from HP. But this has changed since a few years (when the LJ4 came out).
So does Mozilla AFAIR. It just lacks a nice GUI and you need to edit your prefs.js.
Not!. QPL is a OSD compliant license which means its free software - which is the opposite of proprietary.
Its just that some people think its not compatible with the GPL.
So why is this different from warranty?
...
If you care you are free choose a manufacturer
which gives you desired warranty periode on
your HW.
OTOH since there is only a fine line between
HW and SW these days. Should a manufacturer
be liable for software updates or are you
no longer allowed to install any software
without wiping your warranty
Would a SW manufacturer be liable for your
HW/SW combination and thus could forbid you
any updates outside its control?
This is plain wrong.
Even RMS agreed that all code written by the KDE team is compliant with the GPL.
This whole KDE license bashing is all about some minor parts which were not originally written by the KDE team. And it's not even decided on if they have a point at all.
If you look at the current Linux system at
a different view we might already have something along this:
1. Block devices could be plugged in and allow support of different devices. This would be the equiv. of your "Device Managers" and "Partition Managers".
2. On top of the block devices you can layer the RAID and LVM "features modules" which are then available transparently to upper layers.
3. The file system should happily sit on top of this.
Integration among those components may need some work but overall this does not seem that different.
Providing a single administration point for the users is certainly something worthwile but that this is hardly something which could not be done with the current system.
Finally, LVM (any flavour) do just provide a framework. A filesystem does not become resizable
on its own.
Michael
Why do you need raw devices for HA?
All you need is a RAID array which is accessible access from multiple systems (one at a time). So another box can mount the fs of a failed system and take over the work. The components for this are already available (heartbeat, IP switching). All that's needed is a nice framework gluing the existing parts.