I don't know about you, but the goals of IT managers and (l)users seldom are the same.
Agreed. And a setup like this solves nothing when it comes to sharing resources (read: making PC exchange data between them), and it seems to me incredibly stupid to waste 1Gbps to send interrupts from a PCI card on a Cstation or raw ATAPI data around when you can use it to transfer lots of more meaningful data.
It doesn't make sense even if we take it from the point of view of an administrator who has to install software/patches locally: if you have a multi-user system on it, just log in to that machine and do what you have to do (telnet, X protocol, ICA, whatever). If you have a single user system on it, he has to go to the Cstation anyway, since keyboard and display "are there".
Even sending changes in terms of rectangles (or whatever) of pixels is quite expensive, mainly because you have to look at what the changes are in the first place (the graphic engine of the underlying platform may be of great help here).
Although VNC is a Good Thing(TM) when the server runs on a *NIX machine, there are more mature (in terms of performance) products to remotely display Windows applications (i.e. PCAnywhere). VNC people acknowledge this, saying that there is large space for improvements.
But if you need only to run remote X applications and have an X server, a really good solution is compressed X protocol: see the LBX-HOWTO and DXPC in particular (the link in the HOWTO is outdated). With dxpc, 128kbps should be really more than enough for everyday's needs (unless you have to play Quake, of course, or watch a DVD...).
Now, what I'd really like to see is something supporting both this and ICA (and perhaps some local apps in ROM/Flash, since the thing necessarily needs some processing power and RAM in any case).
I also know an answer is "shut up, buy yourself a laptop with 802.11, install Linux on it and on your box in the basement", but a device having a only a compact flash slot (instead of hard disk/floppy/cdrom/etc.) and keyboardless (if you have to type extensively, better go to a desktop anyway) would be IMHO a better (and possibly cheaper?) solution.
Considering that as today there is a lot of people referring to it as the Colossal Disk Eater (`disk' intended as `swap space'), I don't believe it will last long. Perhaps it was "good enough" in the early '90, but for today's standards it is absolutely ugly, cumbersome.
And yes, after ten years it still has nasty bugs (dtterm segfaults, expecially during nigthly builds, dtwm dies with no apparent reason, and the help system just doesn't show up from time to time). Making users switch to KDE or Xfce or Gnome (even on non-Linux systems) is definitively easier.
but in order to be analagous to a Word macro virus, wouldn't emacs have to automatically execute the contents of the file without my direction to do so?
Premise: default values in GNU Emacs regarding the subject are reasonable - so IMHO it's not a problem at all (and it hasn't been in the past, indeed).
Search the GNU Emacs documentation for "Local variables", which are completely safe, except for the "eval" construct.
The default behaviour for Emacs is to show you the code in the eval construct and ask for confirmation. You may change the default behaviour using M-x customize-variable enable-local-eval.
In order to confirm you have to manually type "yes" followed by "Enter", while "no" is the default answer.
So, to give a brief answer: Emacs, by default, doesn't execute the content of a file when it's opened without explicit directions to do so.
Calling DPKG a security problem because it doesn't allow package signing? I'll grant that's kind of valid..
Not necessarily a valid argument, as you can read in an old Freshmeat editorial, where representative of both Debian and RedHat made really interesting points on the subject.
Fix the versioning problem. If the binary standard changes every kernel version, then I can't be expected to use binary, pre-compiled modules
That would mean interfaces written in stone, and layers for backwards compatibility. There are some advantages in doing this from a module developer standpoint. As a drawback, this also means that if something crappy slips into the kernel, or if you don't get the design absolutely right the very first time, it won't ever get out... and this also mean additional work for kernel-developers. It just doesn't work this way.
But then, there are already pretty solutions out there. See how VMWare compiles and installs its kernel modules as needed, for instance: you have a "glue" layer between the kernel and the real code. All kernel dependencies are put in the "glue" layer, VMWare's people mantain it as kernel changes and there's a script (IIRC, launchable from within VMWare with no more than a... mouseclick) that recompiles and installs the module for your current kernel.
Fact: 99% of people CANNOT figure out modules.conf
And here I agree with you. The problem exists, and some effort has been spent on 2.4.x kernels, which are definitively smarter on this. Of course, don't expect a GUI in the kernel for configuring the parameters that cannot be guessed at all. But expect an administrative GUI in userspace (like LinuxConf, or such).
can detect hardware and install it without any knowledge on the users part
Installers are used at installing time -> Linux needs good installers (RH 6.2 installer seems to be on the right direction - to be conservative). But then, let's have a look: how would I expect, say, my mom to install a new hard disk? Probably she'd ask someone more expert even if the installation procedure was absolutely foolproof.
Either such e-books will be printable, so we'll find the following:
Disclaimer: expiration of printed copies of this e-text is based on the honor system. You are requred to print it on our self-destructing paper, or using our special vanishing ink/toner... blah blah blah.
Or they won't be printable at all. In which case, I can assure that e-books for oculists will be the first to came out...
Couldn't we have a Napster topic on the preferences page?
Considering that Napster is basically a indexing service, I'd rather suggest a topic called "Napster Google FTPSearch Altavista Lycos...", thus saving the annoyance of repeated changes during the next few months...
After all, neither you nor me are the ones going to set a borderline on who RIAA should sue and who shouldn't, are we?
Is the *original* opened Netscape source still around?
Doesn't matter. Netscape didn't release the whole source code of Netscape, because it couldn't. The missing pieces are property of third-party manifacturers, and you'd have to recode them if you want a browser working at least as Netscape 4.x
Really, there are reasons why the Mozilla team decided to start from zero some time ago.
The GPL is by far the most restrictive licence ever conceived in this respect, and rather than giving people the freedom to do whatever they wish with the code, it ends up being a straightjacket to restrict their freedom. I would prefer to see more people releasing their code under the BSD license.
Umph, will people ever understand once for all that
Your freedom is my prison
My freedom is your prison
I surely want the freedom of not to be injured by my neighbour. This actually limits my neighbour's freedom to injure me. Now are you telling that for the sake of my neighbour's freedom I should allow him to injure me?
Let's get straight:
People choosing GPL are choosing GPL because they don't want their code to be distributed being part of proprietary code, or to be distributed with proprietary parts. Point.
People choosing BSD are choosing BSD because they want their code to be used by as much as people as possible, regardless if it's used in/with proprietary code or not. Point.
Choose accordingly to your wishes for your code. Other's people code is not yours.
I've never been able to get the color depth under X that I could get from Windows
IIRC, DDC2 allows bidirectional communications between the videocard and the monitor. This gives a way to obtain information on the monitor (i.e. model, characteristics, current setup, etc.) and a way to set parameters on the monitor (contrast, luminosity, geometry correction, etc.). It is handy, because that means that you won't have to look up in the monitor's manual the supported ranges of frequences. But this stops here for what concerns X configuration.
Color depth is a matter of the videocard (and its driver), and DDC shouldn't be of any help here.
If you took care to read their FAQ you'd see that very few of your points are applicabile as now, and that commercial unices are screwed.
To me it seems that ICS is only looking to revititalize a bit what's almost a walking dead. Please consider that bare Motif is almost useless as today: you have to purchase commercial widgets in order to get something comparable with what Qt and GTK provide, and ICS provides such widgets (duh!).
Unfortunately, software requires you to make decisions, and dumbly clicking on "OK" all the time is seen just as a quick way to make the problem go away. Unfortunately, it's not the case. Ideally, the user interface of an application should be engineered and designed to stay flexible intuitive, easy to learn while popping up the minimum number of questions. These goals cannot be accomplished all the times for every situation. In such cases, where the full attention of the user is needed, I'd suggest to force him to use a different input device in order to proceed than the one he usually uses. Today it would mean that you'd have to require confirmation via keyboard (perhaps requiring to type an extensive `yes' instead of a simple `y' (or whatever). I know this may be source of troubles, but I don't see alternatives if questions can't be avoided.
The GNU project exists (well is so big now) because of the Linux kernel, not the other way around
...
BTW it should be Linux/GNU since the kernel is before the programs
In other words, do you really think that gcc, gdb and the binutils were developed because there was the Linux kernel source and the libc that needed to be compiled, or perhaps it was vice-versa?
Surely, gcc is not the only C compiler on the Earth. Nevertheless, having it readily available, free as in speech and as in beer, gave surely a boost in Linux developement (and *BSD, btw), didn't it?
You know: an OS is valuable to commercial mainly because of the software that runs on it. Without an easily portable compiler for Linux, or *BSD, do you really think that there would be anyone making a commercial compiler for a "toy" OS (as Linux was in 1991)? Or would it be always dependant on some commercial compiler like Borland C, or Microsoft C, hacked over all the ways without sources in order to generate code for a different platform ?
The GNU project benefits from the Linux kernel, and the Linux kernel and several other kernels benefit from the GNU project. Telling that it goes only one way or the other is IMHO deeply irrespectful of both. Deal with it.
Again, it seems that someone (ab)used system() once more without checking its arguments first, which is definitively a silly thing to do. There are tons of reasons why one shouldn't trust user input, even if it is in contrast with the KISS principle.
Incidentally, this also means that the remarks in the system(3) manpage are not visible enough (there is a warning about security issues), and that some explicit advice has to be put in the libc info page (there is none). Volunteers?
While I still prefer printed documents over software-only ones, there is one major drawback of printed manuals: they highly tend to disappear somewhere after a few months, usually under a heavy pile of other paper, or on the shelf of some unknown guy that always forgets to give it back... This is bad, because a book may be read only by one at a time, unless you have more copies of the same book.
Given the situation described above, having manuals also in electronic form is a "plus" that personally I like very much, although I see it as no more than a surrogate of the real thing when it's not available.
Of course, software publishers would like to give out software-only documentation in order to transfer the costs to the final users... since they print it anyway. But self-printed manuals tend to be heavy & cumbersome, and while the overall quality is better than the one obtained with LCDs, it is still far from the feel of a book printed by a good tipography.
A couple of months ago, there was a story on Slashdot about IBM working at a 16" 200 dpi LCD color display that could perhaps resolve the problem (200 dpi is almost satisfactory), but IMHO it's a long way to go before we see these spread everywhere.
GPL code is GPL, and people creating derivative products can distribute such products either under GPL or a licence that grants every right that is granted by GPL both to developers and users. In practice, only GPL, AFAIK.
LGPL does not grants every right granted by GPL (WRT users and derivative products), because it allows to distribute derivative products without any right for the users (and other developers) to access of portions of the source code that are not covered by LGPL.
A compromise, in this case, consists in contacting the the legal owner of the code (i.e. the original author, if he didn't pass its copyright to someone else), and convincing him that he really should license that part of code also under a different licence that fit your needs (BSD version 2, LGPL, etc.). The legal owner can always distribute his code under as many licences he likes.
Problem arises when contribution to such code are release only under one of such licences: think a project that is both GPL and BSD, and you receive a GPL contribution - of course it can't be put on BSD without the contributor's permission.
This may look awkward to manage, but it is purely intentional: people who wrote GPL wanted their software to be free and stay free without compromises. If it is not what you wanted, you should choose another kind of licence that best fit your whishes.
Really sorry for the mistakes, I've always believed it was propane and liquified, not petroleum and liquefied, but after a quick check I found I've always been wrong in both cases. Thank you for the corrections.
Re:Possible Uses of the Gathered Data
on
Linux on the Brain
·
· Score: 1
In late eigthties there was a product advertised as a "mental joystick".
It simply sensed electrical activity originated from the muscolar movement of your eyebrows, and translated it in a 4-bit pattern (up, down, left, right).
They claimed you would be able to use it "after litle training". It never take off because there were simplier means, and because only few ever think about possible applications for impaired people.
Hummm, it can't be implemented in cars because they don't have Diesel engines
Well, that may be true in USA.
In Europe there is a looong tradition of cars moved by Diesel engines, mostly turbodiesel with direct injection, which performance is directly comparable (as today almost equal) to gasoline cars, while the engine runs at no more than 3000/4000 RPM (while a gasoline car engine goes up to 7000).
In Europe, Diesel cars are almost as common as gasoline ones, because of the high costs of gasoline (i.e. in Italy it is $1+ per liter - if a gallon is 3.785 liters, do the math).
Just for fun, a real alternative to both Diesel and gasoline in the most part of Europe is no less than the... GPL (liquified propane, which is a problem only in underground parkings).
precompiled headers being probably the largest problem
With gcc you can obtain bare bone headers using -dD. This basically makes cpp to dump rows for #define in addition to the preprocessed code (with definitions).
Simply prepare a file that includes everything you need, preprocess with gcc -E -dD and the usual options you use for your build, and you have the closest thing to a precompiled header which you can directly #include in your sources.
Of course, this may lead to strange results wrt macro expansion (because the code is preprocessed one more time), but with a few lines of Perl you could be able to move all the definitions at the bottom, avoiding the problem and reducing the preprocessor's work. Just my $0.0000001 suggestion. No warranty.
Slashdot Mirror
Agreed. And a setup like this solves nothing when it comes to sharing resources (read: making PC exchange data between them), and it seems to me incredibly stupid to waste 1Gbps to send interrupts from a PCI card on a Cstation or raw ATAPI data around when you can use it to transfer lots of more meaningful data.
It doesn't make sense even if we take it from the point of view of an administrator who has to install software/patches locally: if you have a multi-user system on it, just log in to that machine and do what you have to do (telnet, X protocol, ICA, whatever). If you have a single user system on it, he has to go to the Cstation anyway, since keyboard and display "are there".
I'm missing something?
Loki's SDL with Paragui may be a good start, perhaps.
Even sending changes in terms of rectangles (or whatever) of pixels is quite expensive, mainly because you have to look at what the changes are in the first place (the graphic engine of the underlying platform may be of great help here).
Although VNC is a Good Thing(TM) when the server runs on a *NIX machine, there are more mature (in terms of performance) products to remotely display Windows applications (i.e. PCAnywhere). VNC people acknowledge this, saying that there is large space for improvements.
But if you need only to run remote X applications and have an X server, a really good solution is compressed X protocol: see the LBX-HOWTO and DXPC in particular (the link in the HOWTO is outdated). With dxpc, 128kbps should be really more than enough for everyday's needs (unless you have to play Quake, of course, or watch a DVD...).
Now, what I'd really like to see is something supporting both this and ICA (and perhaps some local apps in ROM/Flash, since the thing necessarily needs some processing power and RAM in any case).
I also know an answer is "shut up, buy yourself a laptop with 802.11, install Linux on it and on your box in the basement", but a device having a only a compact flash slot (instead of hard disk/floppy/cdrom/etc.) and keyboardless (if you have to type extensively, better go to a desktop anyway) would be IMHO a better (and possibly cheaper?) solution.
Considering that as today there is a lot of people referring to it as the Colossal Disk Eater (`disk' intended as `swap space'), I don't believe it will last long. Perhaps it was "good enough" in the early '90, but for today's standards it is absolutely ugly, cumbersome.
And yes, after ten years it still has nasty bugs (dtterm segfaults, expecially during nigthly builds, dtwm dies with no apparent reason, and the help system just doesn't show up from time to time). Making users switch to KDE or Xfce or Gnome (even on non-Linux systems) is definitively easier.
Premise: default values in GNU Emacs regarding the subject are reasonable - so IMHO it's not a problem at all (and it hasn't been in the past, indeed).
Search the GNU Emacs documentation for "Local variables", which are completely safe, except for the "eval" construct.
The default behaviour for Emacs is to show you the code in the eval construct and ask for confirmation. You may change the default behaviour using M-x customize-variable enable-local-eval.
In order to confirm you have to manually type "yes" followed by "Enter", while "no" is the default answer.
So, to give a brief answer: Emacs, by default, doesn't execute the content of a file when it's opened without explicit directions to do so.
Not necessarily a valid argument, as you can read in an old Freshmeat editorial, where representative of both Debian and RedHat made really interesting points on the subject.
That would mean interfaces written in stone, and layers for backwards compatibility. There are some advantages in doing this from a module developer standpoint. As a drawback, this also means that if something crappy slips into the kernel, or if you don't get the design absolutely right the very first time, it won't ever get out... and this also mean additional work for kernel-developers. It just doesn't work this way.
But then, there are already pretty solutions out there. See how VMWare compiles and installs its kernel modules as needed, for instance: you have a "glue" layer between the kernel and the real code. All kernel dependencies are put in the "glue" layer, VMWare's people mantain it as kernel changes and there's a script (IIRC, launchable from within VMWare with no more than a... mouseclick) that recompiles and installs the module for your current kernel.
Fact: 99% of people CANNOT figure out modules.conf
And here I agree with you. The problem exists, and some effort has been spent on 2.4.x kernels, which are definitively smarter on this. Of course, don't expect a GUI in the kernel for configuring the parameters that cannot be guessed at all. But expect an administrative GUI in userspace (like LinuxConf, or such).
can detect hardware and install it without any knowledge on the users part
Installers are used at installing time -> Linux needs good installers (RH 6.2 installer seems to be on the right direction - to be conservative). But then, let's have a look: how would I expect, say, my mom to install a new hard disk? Probably she'd ask someone more expert even if the installation procedure was absolutely foolproof.
Disclaimer: expiration of printed copies of this e-text is based on the honor system. You are requred to print it on our self-destructing paper, or using our special vanishing ink/toner... blah blah blah.
Or they won't be printable at all. In which case, I can assure that e-books for oculists will be the first to came out...
Considering that Napster is basically a indexing service, I'd rather suggest a topic called "Napster Google FTPSearch Altavista Lycos...", thus saving the annoyance of repeated changes during the next few months...
After all, neither you nor me are the ones going to set a borderline on who RIAA should sue and who shouldn't, are we?
Doesn't matter. Netscape didn't release the whole source code of Netscape, because it couldn't. The missing pieces are property of third-party manifacturers, and you'd have to recode them if you want a browser working at least as Netscape 4.x
Really, there are reasons why the Mozilla team decided to start from zero some time ago.
Umph, will people ever understand once for all that
I surely want the freedom of not to be injured by my neighbour. This actually limits my neighbour's freedom to injure me. Now are you telling that for the sake of my neighbour's freedom I should allow him to injure me?
Let's get straight:
People choosing GPL are choosing GPL because they don't want their code to be distributed being part of proprietary code, or to be distributed with proprietary parts. Point.
People choosing BSD are choosing BSD because they want their code to be used by as much as people as possible, regardless if it's used in/with proprietary code or not. Point.
Choose accordingly to your wishes for your code. Other's people code is not yours.
Whey they say Linux, do they mean Linux i386 only or is there any hope to see it for other architectures too?
IIRC, DDC2 allows bidirectional communications between the videocard and the monitor. This gives a way to obtain information on the monitor (i.e. model, characteristics, current setup, etc.) and a way to set parameters on the monitor (contrast, luminosity, geometry correction, etc.). It is handy, because that means that you won't have to look up in the monitor's manual the supported ranges of frequences. But this stops here for what concerns X configuration.
Color depth is a matter of the videocard (and its driver), and DDC shouldn't be of any help here.
To me it seems that ICS is only looking to revititalize a bit what's almost a walking dead. Please consider that bare Motif is almost useless as today: you have to purchase commercial widgets in order to get something comparable with what Qt and GTK provide, and ICS provides such widgets (duh!).
Unfortunately, software requires you to make decisions, and dumbly clicking on "OK" all the time is seen just as a quick way to make the problem go away. Unfortunately, it's not the case. Ideally, the user interface of an application should be engineered and designed to stay flexible intuitive, easy to learn while popping up the minimum number of questions. These goals cannot be accomplished all the times for every situation. In such cases, where the full attention of the user is needed, I'd suggest to force him to use a different input device in order to proceed than the one he usually uses. Today it would mean that you'd have to require confirmation via keyboard (perhaps requiring to type an extensive `yes' instead of a simple `y' (or whatever). I know this may be source of troubles, but I don't see alternatives if questions can't be avoided.
...
BTW it should be Linux/GNU since the kernel is before the programs
In other words, do you really think that gcc, gdb and the binutils were developed because there was the Linux kernel source and the libc that needed to be compiled, or perhaps it was vice-versa?
Surely, gcc is not the only C compiler on the Earth. Nevertheless, having it readily available, free as in speech and as in beer, gave surely a boost in Linux developement (and *BSD, btw), didn't it?
You know: an OS is valuable to commercial mainly because of the software that runs on it. Without an easily portable compiler for Linux, or *BSD, do you really think that there would be anyone making a commercial compiler for a "toy" OS (as Linux was in 1991)? Or would it be always dependant on some commercial compiler like Borland C, or Microsoft C, hacked over all the ways without sources in order to generate code for a different platform ?
The GNU project benefits from the Linux kernel, and the Linux kernel and several other kernels benefit from the GNU project. Telling that it goes only one way or the other is IMHO deeply irrespectful of both. Deal with it.
My 0.02 Euro.
Like "UNIX" containers of metal for high-compressed gas, or like "UNIX" diapers, for example.
Incidentally, this also means that the remarks in the system(3) manpage are not visible enough (there is a warning about security issues), and that some explicit advice has to be put in the libc info page (there is none). Volunteers?
My 0.02 Euro.
Given the situation described above, having manuals also in electronic form is a "plus" that personally I like very much, although I see it as no more than a surrogate of the real thing when it's not available.
Of course, software publishers would like to give out software-only documentation in order to transfer the costs to the final users... since they print it anyway. But self-printed manuals tend to be heavy & cumbersome, and while the overall quality is better than the one obtained with LCDs, it is still far from the feel of a book printed by a good tipography.
A couple of months ago, there was a story on Slashdot about IBM working at a 16" 200 dpi LCD color display that could perhaps resolve the problem (200 dpi is almost satisfactory), but IMHO it's a long way to go before we see these spread everywhere.
My 0.02 Euro.
LGPL does not grants every right granted by GPL (WRT users and derivative products), because it allows to distribute derivative products without any right for the users (and other developers) to access of portions of the source code that are not covered by LGPL.
A compromise, in this case, consists in contacting the the legal owner of the code (i.e. the original author, if he didn't pass its copyright to someone else), and convincing him that he really should license that part of code also under a different licence that fit your needs (BSD version 2, LGPL, etc.). The legal owner can always distribute his code under as many licences he likes.
Problem arises when contribution to such code are release only under one of such licences: think a project that is both GPL and BSD, and you receive a GPL contribution - of course it can't be put on BSD without the contributor's permission.
This may look awkward to manage, but it is purely intentional: people who wrote GPL wanted their software to be free and stay free without compromises. If it is not what you wanted, you should choose another kind of licence that best fit your whishes.
My 0.02 Euro.
Really sorry for the mistakes, I've always believed it was propane and liquified, not petroleum and liquefied, but after a quick check I found I've always been wrong in both cases. Thank you for the corrections.
It simply sensed electrical activity originated from the muscolar movement of your eyebrows, and translated it in a 4-bit pattern (up, down, left, right).
They claimed you would be able to use it "after litle training". It never take off because there were simplier means, and because only few ever think about possible applications for impaired people.
Well, that may be true in USA.
In Europe there is a looong tradition of cars moved by Diesel engines, mostly turbodiesel with direct injection, which performance is directly comparable (as today almost equal) to gasoline cars, while the engine runs at no more than 3000/4000 RPM (while a gasoline car engine goes up to 7000).
In Europe, Diesel cars are almost as common as gasoline ones, because of the high costs of gasoline (i.e. in Italy it is $1+ per liter - if a gallon is 3.785 liters, do the math).
Just for fun, a real alternative to both Diesel and gasoline in the most part of Europe is no less than the... GPL (liquified propane, which is a problem only in underground parkings).
My 0.02 Euro
With gcc you can obtain bare bone headers using -dD. This basically makes cpp to dump rows for #define in addition to the preprocessed code (with definitions).
Simply prepare a file that includes everything you need, preprocess with gcc -E -dD and the usual options you use for your build, and you have the closest thing to a precompiled header which you can directly #include in your sources.
Of course, this may lead to strange results wrt macro expansion (because the code is preprocessed one more time), but with a few lines of Perl you could be able to move all the definitions at the bottom, avoiding the problem and reducing the preprocessor's work. Just my $0.0000001 suggestion. No warranty.
Just to be fair, they recently obtained a C2 on NT4+special service pack+certain hardware, in a networking environment. See here for more info.