Microsoft could learn something from this. The OpenSSH team finds a problem, announces it, and makes a fix available. Then they identify similar problems, announce them, and make fixes available.
Microsoft seems to follow one of three different procedures depending on circumstances: 1. ignore the problem until there's an exploit and public outcry 2. quietly release a fix and then advertise it when there's an exploit and public outcry 3. leave the problem unfixed in order to force people to upgrade
I say we bash Microsoft until they start designing their products with security in mind.
I've always addressed this issue by installing all non-standard software under ~/pkgs and linking executables into ~/bin. That way when I upgrade my laptop, I simply make a tarball of my home directory, ftp it somewhere (or burn it to cd), do a fresh install of whatever distribution I'm moving to (wiping out anything on my HD), and then untaring my home directory tarball. The only thing I have trouble with are dynamically linked executables, so I generally statically link anything that lives in my home directory.
Obviously, I don't do this with huge things like KDE or Gnome, but then I don't particularly care about window managers or desktop environments. Just give me a wm which supports work spaces and alt-tabbing and I'm pretty much happy.
FedEx insures everything up to $100. If you want more insurance, you can get it by paying a little more for it (note the "Declared Value" field on the FedEx Airway bill).
The US government is one of the single largest consumers of computer systems in the world. Is it really surprising that Apple might make an effort to court it?
*BSD gets to benefit from all the Linux development (via Linux emulation if all else fails) and Linux's visability ensures that clueless users will choose it (and presumably stick with it or go back to Windows) while the more savy users (who are better able to contribute back to the community) will recognize when it is advantageous to use *BSD.
Linux is a buffer that protects the *BSD community dilution.
not mach-4. That's crazy talk. they estimated it hit the wing at between 400 and 600 mph, relative to the wing. It may have been going mach-4 in relation to the Earth, but it's the wing that is the important frame of reference here.
You could, but if you can push a mechanism down to the lowest level that supports the objects that the mechanism works on (in this case, into the database), then all applications built above that level can take advantage of the new mechanism without reimplementing it.
Think about it. If you have 10 applications that use a db, do you want to implement clustering/failover once for each application or just once for the db?
I have tried gaming on both the computer and on console and for most types of games, I prefer the console experience. Perhaps this is because I'm not a serious gamer, but then, the majority of people who are potential game players aren't serious gamers either.
Console games need to be designed such that the limited input allowed by the controller can still provide a natural way of interfacing with the game. Computers have more interface options. If a game requires a more complicated interface than a console provides, then the game will always provide a better experience on a computer than a console. However, many (most?) games play just fine on a console and when given a choice between playing a game on a computer or a console, I will almost always choose to play on the console rather than the computer.
Part of this might be that I work on computers and so feel a need to get away from the computer when I'm not doing things that require a computer, but I'm pretty sure I felt this way when I was younger and the computer was just another toy.
As long as you have all the libraries installed (which the distro will probably take care of for you), you can run GNOME apps under KDE (or any other window manager) and vice versa.
This is a non-issue. I don't know why everyone keeps bringing this up.
HP has people who do nothing but try to sell Linux solutions to business. Earlier this year, FedEx expressed interest in Linux to HP and HP sent over fairly knowledgable people to try to explain Linux to management and show how HP could help us move several of our projects over to Linux (it was amusing when they came to our department because we're already using Linux every day).
So, think what you want about HP's support of Linux, but there are at least some people at HP who are excited about Linux and are willing to spend time and money helping customers evaluate Linux solutions.
These were bourne shell scripts that ran before either bash OR perl existed on the machine. Maybe bash and perl are part of Solaris now (I don't know if that's true), but they weren't then--you installed them after the basic install was finished.
I agree with you that for non-trivial scripts, Ruby, Perl, or Python (my preference is Python) are better choices, but they are not always available. In my case, we were writing scripts to automate machine installation and weren't guaranteed to have more powerful tools available to us on every platform.
Just because one tool is generally better doesn't mean it is appropriate in every circumstance.
I believe you misread my post if you think I'm advocating writing shell scripts in csh or tcsh. I clearly said that I wrote my shell scripts in bourne shell.
I was a big fan of tcsh until I started doing serious shell scripting in a heterogeneous environment. Since tcsh wasn't available on all machines, all shell scripts were written for the bourne shell. After several months of using bourne shell syntax for scripts but using tcsh shell syntax on the command line, I finally decided that in order to preserve my sanity, I'd try bash on the command line. Turns out that after a day or so to get used to things, bash had everything I used tcsh for plus a couple of features that I'd never known would be so useful.
I don't like running scripts under bash because it's so big, but as an environment, it's pretty decent.
You don't need a driver to print via an Eltron (or any Zebra) printer. You can send print strings straight over a serial cable or, if your printer is networked, simply open a socket to it. We generate FedEx labels on both Linux and Solaris (for Intel). It's custom code, but creating print strings is essentially no different than creating valid XML or HTML. It's just another mark up language.
Slashdot Mirror
Perhaps the low-latency fixes add overhead. 2.6 might feel faster
because of this but might actually run slower.
Microsoft could learn something from this. The OpenSSH team finds a problem,
announces it, and makes a fix available. Then they identify similar problems,
announce them, and make fixes available.
Microsoft seems to follow one of three different procedures depending on
circumstances:
1. ignore the problem until there's an exploit and public outcry
2. quietly release a fix and then advertise it when there's an exploit and
public outcry
3. leave the problem unfixed in order to force people to upgrade
I say we bash Microsoft until they start designing their products with
security in mind.
I've always addressed this issue by installing all non-standard
software under ~/pkgs and linking executables into ~/bin. That
way when I upgrade my laptop, I simply make a tarball of my
home directory, ftp it somewhere (or burn it to cd), do a fresh
install of whatever distribution I'm moving to (wiping out anything
on my HD), and then untaring my home directory tarball. The only
thing I have trouble with are dynamically linked executables, so
I generally statically link anything that lives in my home directory.
Obviously, I don't do this with huge things like KDE or Gnome, but
then I don't particularly care about window managers or desktop
environments. Just give me a wm which supports work spaces and
alt-tabbing and I'm pretty much happy.
Please post references to back this up.
Every time I decide to investigate this, everything I can come up with
indicates that only Microsoft takes this approach.
FedEx insures everything up to $100. If you want more insurance, you can
get it by paying a little more for it (note the "Declared Value" field
on the FedEx Airway bill).
Has anyone seen the report?
I'd like to know what the 12 projects were that were being compared to
see if the comparisons make sense.
Is there any chance at all that this is an actual apples to apples
comparison?
The US government is one of the single largest consumers of computer
systems in the world. Is it really surprising that Apple might make
an effort to court it?
Why get a Linux distro that's trying to be OpenBSD when
you can get OpenBSD for the same price?
That's my question, too. We bought 2 machines from
Dell in 1999 that RedHat 6.2 (I think) preinstalled
on them.
Maybe HP is the first big distributer to advertise.
Linux is the best thing to ever happen to *BSD.
*BSD gets to benefit from all the Linux development
(via Linux emulation if all else fails) and Linux's
visability ensures that clueless users will choose
it (and presumably stick with it or go back to Windows)
while the more savy users (who are better able to
contribute back to the community) will recognize when
it is advantageous to use *BSD.
Linux is a buffer that protects the *BSD community
dilution.
Think about it.
Surely there are studies that have addressed this sort of cost.
It seems too obvious to overlook.
Of course, a quick google search returned nothing intresting.
not mach-4. That's crazy talk. they estimated it hit the wing
at between 400 and 600 mph, relative to the wing. It may have
been going mach-4 in relation to the Earth, but it's the wing
that is the important frame of reference here.
So what's your complaint with Red Hat?
What are inverse and shadow keys used for?
two questions:
Is it a bug or just a known limitation?
Is this still an issue with current version?
You could, but if you can push a mechanism down to the lowest level that
supports the objects that the mechanism works on (in this case, into the
database), then all applications built above that level can take advantage
of the new mechanism without reimplementing it.
Think about it. If you have 10 applications that use a db, do you want to
implement clustering/failover once for each application or just once for the
db?
I have tried gaming on both the computer and on console and for most types
of games, I prefer the console experience. Perhaps this is because I'm not
a serious gamer, but then, the majority of people who are potential game
players aren't serious gamers either.
Console games need to be designed such that the limited input allowed by
the controller can still provide a natural way of interfacing with the game.
Computers have more interface options. If a game requires a more complicated
interface than a console provides, then the game will always provide a
better experience on a computer than a console. However, many (most?) games
play just fine on a console and when given a choice between playing a game
on a computer or a console, I will almost always choose to play on the
console rather than the computer.
Part of this might be that I work on computers and so feel a need to get
away from the computer when I'm not doing things that require a computer,
but I'm pretty sure I felt this way when I was younger and the computer was
just another toy.
As long as you have all the libraries installed (which the distro
will probably take care of for you), you can run GNOME apps under
KDE (or any other window manager) and vice versa.
This is a non-issue. I don't know why everyone keeps bringing this
up.
Please define "recurring bugs you have the fix for".
It seems that if the bug is recurring, then you haven't
got a fix, just a temporary band-aid.
HP has people who do nothing but try to sell Linux solutions to business.
Earlier this year, FedEx expressed interest in Linux to HP and HP sent
over fairly knowledgable people to try to explain Linux to management and
show how HP could help us move several of our projects over to Linux
(it was amusing when they came to our department because we're already
using Linux every day).
So, think what you want about HP's support of Linux, but there are at least
some people at HP who are excited about Linux and are willing to spend time
and money helping customers evaluate Linux solutions.
These were bourne shell scripts that ran before either bash OR perl
existed on the machine. Maybe bash and perl are part of Solaris now
(I don't know if that's true), but they weren't then--you installed them
after the basic install was finished.
I agree with you that for non-trivial scripts, Ruby, Perl, or Python
(my preference is Python) are better choices, but they are not always
available. In my case, we were writing scripts to automate machine
installation and weren't guaranteed to have more powerful tools
available to us on every platform.
Just because one tool is generally better doesn't mean it is appropriate
in every circumstance.
I believe you misread my post if you think I'm advocating writing shell scripts
in csh or tcsh. I clearly said that I wrote my shell scripts in bourne shell.
BTW, what is "Finux"?
I was a big fan of tcsh until I started doing serious shell scripting in
a heterogeneous environment. Since tcsh wasn't available on all machines, all
shell scripts were written for the bourne shell. After several months of
using bourne shell syntax for scripts but using tcsh shell syntax on the
command line, I finally decided that in order to preserve my sanity, I'd try
bash on the command line. Turns out that after a day or so to get used to
things, bash had everything I used tcsh for plus a couple of features that
I'd never known would be so useful.
I don't like running scripts under bash because it's so big, but as an
environment, it's pretty decent.
You don't need a driver to print via an Eltron (or any Zebra) printer.
You can send print strings straight over a serial cable or, if your
printer is networked, simply open a socket to it. We generate FedEx
labels on both Linux and Solaris (for Intel). It's custom code, but
creating print strings is essentially no different than creating
valid XML or HTML. It's just another mark up language.