Actually, McNealy doesn't get it yet but he
is shooting himself in the foot because he
is promoting MS vision of the internet and
thus trying to play on MS terms. Microsoft
is trying to build an integrated network
experience and trying to lock customers to
store their prefs in MS formats. McNealy's
arguments today will inevitably drive his
company out of business once it becomes
impossible to do e-commerce without MS software
(oh, about 3-10 years, I'd guess).
Well, I think most courts would consider "use" of
source code to be compilation thereof. The
benefit of having source is not that you can
modify it, but that you can compile it against
your setup with the optimizations you want.
This is similar to having a PDF of a book. The
"use" would be your ability to print it on any
paper you wanted not to plagiarize it by
taking you words and the original work and
"merging them together (usually in some coherent
way that works)".
Face it, he did not mention modification, and
as GNU documentation says (my paraphrase from
memory): nothing else grants you any rights
with respect to this software.
Hmm, I never thought about it that way but
it looks like Linux distros are pioneering
the street performer protocol in a more or
less unadulterated form. Neat.
Uh, I want to have whatever it is you're
smoking. Journaling doesn't protect your data.
The risk of data loss is about same as
with non-journaling FS. The only thing that
is protected by journaling is meta-data, i.e.
your FS structure. The only way to protect
your data is via mirrored RAID.
The guy's homepage makes it sound like this is
his effort to explore OS design not to design
yet another OS for mass consumption, which may
be why he is not looking for help.
I used to bash X a lot based exactly on
the things you mentioned (esp. its
networking capability). Then I realized
that you can summarize problems with X
much more coherently: X is not part of
kernel. Every other X shortcoming comes from
this fact.
If you need to RTFM to use something then it is
effectively unusable for most people. Most people
have trouble understanding the difference between
"Save" and "Save As" options, so why do you
think they'd be able to learn the difference
between ":q", ":q!", and ":x". Do you know what
happens when average people are shown a terminal
runnign vi? The can't understand why no letters
show up on screen and the thing beeps every time
they press the keyboard. Some stumble on the "i"
key and are puzzled why the behavior has changed
when all they did was press another letter.
I have personally spent FIVE hours trying to
teach someone what the "INSERT" key on the
keyboard does (in DOS). I failed. Miserably.
I suggest you try to teach your grandmother this
very fact. Then write back if you hadn't had an
epiphany.
Oh, and imagine you are a company trying to teach
your middle-school-dropout secretaries how to use
vi (let's be generous and say vim). Suddenly the
cost becomes tangible, measured in real dough.
To extend your proposal, it would be nice if you
could admin your own machine. This would save you
time. If all secretaries in a big company had
basic sysadmin's skills you wouldn't need tech
support. Imagine the savings. Yet noone does this.
Why? Because your ninja sysadmin secretaries
would have too many skills, would command higher
salaries and most importantly, would cost waaay
too much to train.
Bottom line, most people will find RTFMing a
prohibitive cost of entry, so that without
GUI they will not be productive at all.
I have been a grader in a junior-level
physics course required for physics majors.
The thing about the course was that the
professor was lazy and never changed homework
assignments year after year AND after the
homework was graded he gave out his own
canonical solutions. By the time I came along
I had a good chunk of homeworks with the same
varibale names, diagrams etc. as the original
canonical solution. I told the professor, the
professor appealed to the class for integrity,
then the homeworks became reworded versions of
canonical solution. At that point it became hard
for me to claim plagiarism and that was that.
I'd guess about 20% were cheating.
The thing is though that this usually happens with
obligatory classes, the ones where the students
just want to be done with and consequently
professor feels the same. If a class is elective
people will only take it if they are motivated.
Then it is reasonable to expect and even demand
the honor system to work.
Re:"Once 1.0 hits the net..."
on
Mozilla 0.9 Out
·
· Score: 1
I wonder you accept this as fact rather than
flaw in numbering scheme. If it says it's
a stable release it should be stable.
Re:"Once 1.0 hits the net..."
on
Mozilla 0.9 Out
·
· Score: 1
Well, I personally only care about mozilla
BECAUSE they take their time. I want to see
a PERFECT 1.0 release and be able to use
this as an example of people doing the
right thing: releasing when it's ready.
Remember, free software is not written for
users, it is written for developers themselves
or to quote the waaay overused phrase - "to
scratch their own itch". I want to see what
lack of marketoid pressure produces in the end.
This is a test.
I said "some hardware readout device".
I am working in a physics lab. I have access
to multimillion dollar microscopic equipment.
Reading micron-large circuits isn't a big
problem. People reverse-engineer microchips
by going thru their physical layout. It's
very doable.
My point is you can't trust the user, since there
may be power users out there with powerful
reverse-engineering facilities.
Many people here seem to think this is a
good thing. What they forget is that with
this device a doctor can tell when/whether
grampa is doing any physical activity vs.
resting/sleeping. This creates a precedent
for putting monitoring devices in humans.
Just wait until your HMO requires you to have
e.g. a sound level meter implanted, such that
if you are exposed to too much noise then
they can deny you hearing coverage.
I think this is VERY BAD, especially since they
try to present it as a "patient management" tool,
in an explicit attempt to reduce your face to
face time with your doctor.
Wait, but they try to protect monitor, i.e.
monitor-computer connection is assumed
insecure. Besides you can't embed a key in
either computer or monitor because both
devices are in user control so keys can
then be extracted via some hardware readout
device. You must dinamically generate key
pairs without communicating with the other
device, i.e. symmetric schemes are not suited
for the task of securing the monitor.
Furthermore, my question indeed had to do with
making brute-forcing harder by using absurd
length keys.
Again, what am I missing?
It blows my mind that people would consider
using 56-bit keys anywhere esp. in devices
with several years lifetime. They can have
en/dec-ryption in hardware so speed wouldn't
be an issue so why not have say 4096 bit
encryption? What am I missing?
Ok, now you have me confused. The number one
area where object oriented programming matters
is GUI, precisely because GUI programs involve
"objects, and actions on said objects". Or maybe
by graphics programming you mean something like
Autocad (oh wait, it's all LISP underneath).
So what kind of graphics programs is LISP not
suited for?
First, I have never coded anything system-level
and do not actively code now at all. Second,
this was not a rant about what makes free
unices bad, rather a suggestion of where work
is needed. Third, "proprietary" just means it
has to be reverse engineered rather than working
by spec - people do that, I am not one of these
people. If I were to write something it'd be
a down-to-earth human-usable version of
IBM's Data Explorer (which is itself free).
Since crypto is mentioned, I'll ask a
question that bothered me for a while.
Say you had a message and a key, such that
both were identical. What encryption
algorithm today would be most secure
under this setting.
Example: store password encrypted with
itself. When user enters password, decrypt
encrypted message and compare with password
entered. Given that passwords are small
eficiency of algrotithm is unimportant.
What is the best encryption method (defined
as time to decryption on a predefined turing
machine) for this purpose?
Nice reference. As for oxygen content,
you can estimate it from T_c. In fact,
oxygen content changes with time, so
I wonder if commercial tapes have a
limited life-span. Keeping the tapes
at LN2 will help, but even so oxygen
diffusion will happen.
BSCCO indeed is nice and safe and non-toxic
but from engineering perspective hard to
work with. It cleaves easily and is brittle.
YBCO is better in that sense.
Lastly, do you know the procedure (hasmat) for
working with TBCO? Any nasty things from
handling it?
All superconductors have a characteristic
called critical current. Go above it and
superconductivity is destroyed. The lower the
temperature, the higher the critical current.
The CNN article makes it sound like they will
do what you call bronze access and charge
between $5 and $15 for it.
http://www.cnn.com/2001/TECH/computing/01/29/fee .b ased.napster.idg/index.html
Highly unlikely, IMHO. Sand is a good example.
Grains must be modeled with polygon-based models
because as your character gets closer, these
grains will have to be rendered properly. If your
game has a magnifying glass (or curved mirrors)
you'd better have enough polygon count per grain
to make zooms possible. Let's assume you can see
1 km square area, and we'll say land is only
100 m deep, as even strong explosions in real
life are unlikely to go deeper. You then have
~10^18 grains (assuming each grain ~1/2 mm dia.).
We'll assume 100 polygons to be enough to model
a grain. Then you need 10^20 polygons to render
the ground properly. Of course almost all polygons
will be invisible in any given scene, but your
hardware will still have to decide which ones to
render.
To summarize: yes, most complexity will not be
seen by human eye, but no that doesn't enable
realistic rendering. The more realistic you try
to get your game, the more resources you'll have
to dedicate to deciding what to render, so that
actual rendering may not be the limiting factor
but your game will still crawl (on geological
time scale).
Most movies go for $20. If your burn success
rate it 1 of 2 you'd be better advised to buy
movies. I'd say this pricing makes piracy
marginally economical but just that. Still,
once the movie piracy gets like for CDs, it
might be attractive.
Slashdot Mirror
Actually, McNealy doesn't get it yet but he
is shooting himself in the foot because he
is promoting MS vision of the internet and
thus trying to play on MS terms. Microsoft
is trying to build an integrated network
experience and trying to lock customers to
store their prefs in MS formats. McNealy's
arguments today will inevitably drive his
company out of business once it becomes
impossible to do e-commerce without MS software
(oh, about 3-10 years, I'd guess).
Well, I think most courts would consider "use" of
source code to be compilation thereof. The
benefit of having source is not that you can
modify it, but that you can compile it against
your setup with the optimizations you want.
This is similar to having a PDF of a book. The
"use" would be your ability to print it on any
paper you wanted not to plagiarize it by
taking you words and the original work and
"merging them together (usually in some coherent
way that works)".
Face it, he did not mention modification, and
as GNU documentation says (my paraphrase from
memory): nothing else grants you any rights
with respect to this software.
Hmm, I never thought about it that way but
it looks like Linux distros are pioneering
the street performer protocol in a more or
less unadulterated form. Neat.
> what did you think I was talking about?
You were talking about, and I quote:
>> Replace [snip]"less risk of data loss" with "no risk of data loss"
Uh, I want to have whatever it is you're
smoking. Journaling doesn't protect your data.
The risk of data loss is about same as
with non-journaling FS. The only thing that
is protected by journaling is meta-data, i.e.
your FS structure. The only way to protect
your data is via mirrored RAID.
The guy's homepage makes it sound like this is
his effort to explore OS design not to design
yet another OS for mass consumption, which may
be why he is not looking for help.
I used to bash X a lot based exactly on
the things you mentioned (esp. its
networking capability). Then I realized
that you can summarize problems with X
much more coherently: X is not part of
kernel. Every other X shortcoming comes from
this fact.
If you need to RTFM to use something then it is
effectively unusable for most people. Most people
have trouble understanding the difference between
"Save" and "Save As" options, so why do you
think they'd be able to learn the difference
between ":q", ":q!", and ":x". Do you know what
happens when average people are shown a terminal
runnign vi? The can't understand why no letters
show up on screen and the thing beeps every time
they press the keyboard. Some stumble on the "i"
key and are puzzled why the behavior has changed
when all they did was press another letter.
I have personally spent FIVE hours trying to
teach someone what the "INSERT" key on the
keyboard does (in DOS). I failed. Miserably.
I suggest you try to teach your grandmother this
very fact. Then write back if you hadn't had an
epiphany.
Oh, and imagine you are a company trying to teach
your middle-school-dropout secretaries how to use
vi (let's be generous and say vim). Suddenly the
cost becomes tangible, measured in real dough.
To extend your proposal, it would be nice if you
could admin your own machine. This would save you
time. If all secretaries in a big company had
basic sysadmin's skills you wouldn't need tech
support. Imagine the savings. Yet noone does this.
Why? Because your ninja sysadmin secretaries
would have too many skills, would command higher
salaries and most importantly, would cost waaay
too much to train.
Bottom line, most people will find RTFMing a
prohibitive cost of entry, so that without
GUI they will not be productive at all.
I have been a grader in a junior-level
physics course required for physics majors.
The thing about the course was that the
professor was lazy and never changed homework
assignments year after year AND after the
homework was graded he gave out his own
canonical solutions. By the time I came along
I had a good chunk of homeworks with the same
varibale names, diagrams etc. as the original
canonical solution. I told the professor, the
professor appealed to the class for integrity,
then the homeworks became reworded versions of
canonical solution. At that point it became hard
for me to claim plagiarism and that was that.
I'd guess about 20% were cheating.
The thing is though that this usually happens with
obligatory classes, the ones where the students
just want to be done with and consequently
professor feels the same. If a class is elective
people will only take it if they are motivated.
Then it is reasonable to expect and even demand
the honor system to work.
I wonder you accept this as fact rather than
flaw in numbering scheme. If it says it's
a stable release it should be stable.
Well, I personally only care about mozilla
BECAUSE they take their time. I want to see
a PERFECT 1.0 release and be able to use
this as an example of people doing the
right thing: releasing when it's ready.
Remember, free software is not written for
users, it is written for developers themselves
or to quote the waaay overused phrase - "to
scratch their own itch". I want to see what
lack of marketoid pressure produces in the end.
This is a test.
I said "some hardware readout device".
I am working in a physics lab. I have access
to multimillion dollar microscopic equipment.
Reading micron-large circuits isn't a big
problem. People reverse-engineer microchips
by going thru their physical layout. It's
very doable.
My point is you can't trust the user, since there
may be power users out there with powerful
reverse-engineering facilities.
Many people here seem to think this is a
good thing. What they forget is that with
this device a doctor can tell when/whether
grampa is doing any physical activity vs.
resting/sleeping. This creates a precedent
for putting monitoring devices in humans.
Just wait until your HMO requires you to have
e.g. a sound level meter implanted, such that
if you are exposed to too much noise then
they can deny you hearing coverage.
I think this is VERY BAD, especially since they
try to present it as a "patient management" tool,
in an explicit attempt to reduce your face to
face time with your doctor.
Wait, but they try to protect monitor, i.e.
monitor-computer connection is assumed
insecure. Besides you can't embed a key in
either computer or monitor because both
devices are in user control so keys can
then be extracted via some hardware readout
device. You must dinamically generate key
pairs without communicating with the other
device, i.e. symmetric schemes are not suited
for the task of securing the monitor.
Furthermore, my question indeed had to do with
making brute-forcing harder by using absurd
length keys.
Again, what am I missing?
It blows my mind that people would consider
using 56-bit keys anywhere esp. in devices
with several years lifetime. They can have
en/dec-ryption in hardware so speed wouldn't
be an issue so why not have say 4096 bit
encryption? What am I missing?
Ok, now you have me confused. The number one
area where object oriented programming matters
is GUI, precisely because GUI programs involve
"objects, and actions on said objects". Or maybe
by graphics programming you mean something like
Autocad (oh wait, it's all LISP underneath).
So what kind of graphics programs is LISP not
suited for?
>>I only have time to talk about it. Does anyone
>>have the time to actually do it?
Ahh, the spirit of open source...
First, I have never coded anything system-level
and do not actively code now at all. Second,
this was not a rant about what makes free
unices bad, rather a suggestion of where work
is needed. Third, "proprietary" just means it
has to be reverse engineered rather than working
by spec - people do that, I am not one of these
people. If I were to write something it'd be
a down-to-earth human-usable version of
IBM's Data Explorer (which is itself free).
You forgot the number one thing: get scanners
and winmodems working automagically. Both
currently lack drivers to say nothing of
autodetect features.
Since crypto is mentioned, I'll ask a
question that bothered me for a while.
Say you had a message and a key, such that
both were identical. What encryption
algorithm today would be most secure
under this setting.
Example: store password encrypted with
itself. When user enters password, decrypt
encrypted message and compare with password
entered. Given that passwords are small
eficiency of algrotithm is unimportant.
What is the best encryption method (defined
as time to decryption on a predefined turing
machine) for this purpose?
Nice reference. As for oxygen content,
you can estimate it from T_c. In fact,
oxygen content changes with time, so
I wonder if commercial tapes have a
limited life-span. Keeping the tapes
at LN2 will help, but even so oxygen
diffusion will happen.
BSCCO indeed is nice and safe and non-toxic
but from engineering perspective hard to
work with. It cleaves easily and is brittle.
YBCO is better in that sense.
Lastly, do you know the procedure (hasmat) for
working with TBCO? Any nasty things from
handling it?
All superconductors have a characteristic
called critical current. Go above it and
superconductivity is destroyed. The lower the
temperature, the higher the critical current.
The CNN article makes it sound like they wille .b ased.napster.idg/index.html
do what you call bronze access and charge
between $5 and $15 for it.
http://www.cnn.com/2001/TECH/computing/01/29/fe
Highly unlikely, IMHO. Sand is a good example.
Grains must be modeled with polygon-based models
because as your character gets closer, these
grains will have to be rendered properly. If your
game has a magnifying glass (or curved mirrors)
you'd better have enough polygon count per grain
to make zooms possible. Let's assume you can see
1 km square area, and we'll say land is only
100 m deep, as even strong explosions in real
life are unlikely to go deeper. You then have
~10^18 grains (assuming each grain ~1/2 mm dia.).
We'll assume 100 polygons to be enough to model
a grain. Then you need 10^20 polygons to render
the ground properly. Of course almost all polygons
will be invisible in any given scene, but your
hardware will still have to decide which ones to
render.
To summarize: yes, most complexity will not be
seen by human eye, but no that doesn't enable
realistic rendering. The more realistic you try
to get your game, the more resources you'll have
to dedicate to deciding what to render, so that
actual rendering may not be the limiting factor
but your game will still crawl (on geological
time scale).
Most movies go for $20. If your burn success
rate it 1 of 2 you'd be better advised to buy
movies. I'd say this pricing makes piracy
marginally economical but just that. Still,
once the movie piracy gets like for CDs, it
might be attractive.