I've never seen someone fired for not having a degree
unless they lied about it.
But I've certainly seen people not hired in the first place
for not having a degree -- which probably explains why
some people wind up lying about it in the first place.
The BSD license isn't the same as public-domain.
The only person who can change the license is the
copyright holder.
Sure, you can GPL your own changes to the BSD-licensed
code, and distribute those changes as such.
And you don't have to resistribute the original, since
it wasn't GPL'd.
But you can't redistribute the whole thing as GPL, because
you don't have the copyright to the original.
This is probably the second of the most common misconception concerning
of the BSD license.
The most common misunderstanding is the idea that the BSD license
allows people to "steal" the code and make it proprietary.
That's false -- they are in the same position that you
are.
They can only make proprietary their changes and additions
to the code.
The original is as freely available as it ever was,
as are all changes released under the original license.
There is no added impetus to fork the BSD-licensed
(and thus publically available)
version.
I don't see much use in arguing over whether the GPL or the
BSDL is more "free" -- such discussions tend to turn on
semantic hair-splitting or contrived examples
and probably have more to do with
the personal inclinations of the people arguing than
anything else.
My own feeling is that both licenses have their place
and there relative "freeness" depends upon the situation.
I appreciate the joke, but just to make a point:
the lawyers are involved (and paid) whether a case
ever is heard in a courtroom or not.
And, in fact, an early trial might be quite a bit
cheaper than all the filings and counterfilings
that the lawyers wind up preparing.
You nailed this one!
Murdoch is after market share, and will support whatever
political viewpoint gives it to him.
But I doubt if he has any much allegiance to any country --
even Australia -- only to himself.
Steve Russell -- created first digital computer video game.
Nolan Bushnell -- created first video game business.
Ralph Baer -- created pong.
Am I keeping score correctly here?
I'm sure there are a lot of firsts that could be added to this list.
But I think the point is that you had better be sure what child you're talking about before asserting paternity.
One cure for the 100 ft cable is to use a second 100 ft cable
-- to a pair of headphones.
I'm surprised no one thought of that, or perhaps Jimi
didn't like the idea of wearing cans [jargon for headphones]
in concert.
Once upon a time (prior to 1978)
there was no lseek()
call in Unix.
The value for the offset was 16 bits.
Larger seeks were handled by using the different
value for "whence" (the third argument to seek())
which causes seeks
to occur in 512-byte increments.
This resulted in a maximum seek of 16,777,216
bytes, with an arbitrary seek()
often requiring two
calls, one to get to the right 512-byte block and
a second to get to the right byte within the block.
(Thank goodness they haven't done any such silliness
to break the 2GB barrier.)
When Research Edition 7 Unix came out, it introduced
lseek() with a 32-bit offset.
2,147,483,648 bytes should be enough for anyone,
hmmm?:-).
The FreeBSD folks have already done a considerable amount of
work on this, even to the point of making time_t 64 bits
for both kernel and userland and testing for issues.
Enough is known that the main worry now is how to handle
the change in ports, some of which need a fair amount
of work to move away from 32-bit time_t.
But at the rate things are going, I'd expect that they will
make the transition to 64-bit time_t for FreeBSD 6.0.
I've no idea how they will handle the legacy issues
(ports and pre-6.0 binaries) though.
As long as there is no hardware base DRM involved, the "hackers" will always catch up within days.
Exactly.
And much as I hate to say it, this is why such hardware is inevitable.
That's not to say that there won't be a thriving
underground of hardware and software hackers who
will work around most every DRM techniue that comes down
the line; consider Satellite TV, for a contemporary example.
But by the end of the decade hardware-based DRM will
be nearly universal.
The RIAA and MPAA haven't produced enough solid
evidence of economic loss
to justify the enormous costs of the change
to DRM hardware.
But it's only a matter of time before such evidence is
found -- or manufactured.
And although I don't expect many people here to follow along,
as more and more content is released in DRM-protected
form, John Q. Public will eventually cave and acquire
the necessary hardware (the cost of which will probably be subsidized by a "tax" on the exclusive content).
-Ed
Re:In case you didn't figure it out from the artic
on
FreeBSD Kernel Leak
·
· Score: 3, Informative
The problem isn't calling just calling
fpathconf() repetitively.
The problem is calling fpathconf() repetitively
on a socket or other non-file (which would be
a bug in itself).
And by "repetitively" I mean at least 2,147,483,648 times
on the same file descriptor for a system panic
exploit, and exactly 4,294,967,295 times
on the same file descriptor (followed
by a close()) for the priviledge escalation exploit.
No network daemon that is part of the FreeBSD base system
can be coerced into performing the necessary actions.
Grep the source tree yourself (you'll only get a handful
of hits) and examine the resulting files if you don't
believe me.
It's impossible to rule out everything in the ports collection
(and the FreeBSD folks are careful not to make any claims
regarding them) but it's hard to imagine creating
an exploit of greater than
theoretical importance
using any network server.
-Ed
In case you didn't figure it out from the article
on
FreeBSD Kernel Leak
·
· Score: 5, Informative
This is a local vulnerability;
it doesn't, in and of itself, make servers vulnerable.
Even if someone has a local account on a system, it takes
hours of CPU time to perform an exploit.
It looks like the bug (and the fix) were already announced
(and committed to CVS) but that the possibility of using the
bug in an exploit was not revealed until now (and might not
even have been appreciated by the original reporter).
-Ed
Why not? Lots of people google for employees
on
Googling For Dates?
·
· Score: 3, Interesting
A lot of folks I know use Google to check out
resumes and otherwise see what sort of projects
a job candidate has been up to.
People used to use DejaNews (back before it
was "Google Groups") to do the same thing.
I'll not comment on whether I consider this ethical or not,
but it makes a certain practical sense.
But it makes a bit less sense for a date, however, given that
the person's online persona may be under a different name,
or may be partly or wholly an invention.
Still, if I'm dating a (presumed) professional who is likely
to have formal or informal writings that may be on the
web, it would make sense to "check."
I'd personally feel icky doing so, but others wouldn't
have qualms...
Change, and the new superseding the old, is what the
Silicon Valley is all about.
Yes, companies come and go, but it isn't
the companies, per se, that make SV what it is.
It's the human infrastructure, the critical mass of
talent that is always ready to move on and create
the next "great thing."
-Ed
Et tu, Slashdot?
on
The Be Lives!
·
· Score: 5, Insightful
If someone posted this in the Slashdot Linux section
(if it had one -- it doesn't need one, for reasons
that are pretty obvious to all), we'd be virtually
buried under a blizzard of "Be isn't Free
Software/Be isn't Linux/How dare you compare Be
with Linux" postings.
Think about it& -- you know it's true.
Of course, I'm going to get hammered with negative moderations
for suggesting that Slashdot itself has joined with the
BSD Is Dying troll in wanton BSD-bashing, but how
else can we interpret this?
I try to be impartial; hell, I've run Linux since
Yggsadril, and the computer nearest my left foot is
running RedHat 7.2 (plus a customized kernel and security
patches) while the one nearest my right foot runs
FreeBSD 4.6-RELEASE.
I read the LKML and a few freebsd-* mailing lists.
My Alpha runs Linux, since Linux supports it better
than any flavor of BSD.
And I firmly believe that Linux is the best shot the free
software community has against Microsoft.
And, of course, Linux != Slashdot, so I'll continue to
use and support it as much as I always have.
But now I have to say that the anti-BSD bias on Slashdot,
which has been strongly hinted at before, has become
starkly obvious.
The mentality of many Slashdotters -- that Linux and
BSD are somehow in competition rather than allies in
the battle against Redmond -- seems to be
infiltrating Slashdot itself.
It's been subtle in the past, evidenced when major BSD
events are simply ignored while random fluff gets
reported.
Now, it comes right out in the open.
I guess I've been in denial.
None of this is to be taken as slander against Be, which
is about as fine a closed-source, not-really-free product
as I've ever seen.
It doesn't belong in the BSD section,
however, and putting it here should
be as much an insult against Be as it is against BSD.
Intel isn't exactly betting the farm on the PC market, either.
Although Itanium isn't quite as do-or-die for Intel as the
Hammer series is for AMD, they both
know full well that making
CPU's for PC's will be a shrinking part of their revenues.
Making chips for servers is the market they are both shooting
for.
The margins are much higher and the market is actually
growing at a good clip, unlike the PC market.
So I guess this may be bad news for folks who want really
cheap bleeding-edge performance on their desktops.
But business users don't need any more performance on the
desktop than
they already have, and even gamers are increasingly
looking toward GPU's and not CPU's as the most important
factor for performance in their systems.
Intel and AMD are laying their bets in the server room.
Given that AMD already has the technology in hand to
deliver more bang-per-buck than Itanium and with a smooth
and solid migration path, this may be the most sensible
move they've made in years.
I want something with genuine firepower.
Not something that attempts to overcome
burglars by giving them a case of the giggles.
-Ed
Re:ya, I couldn't talk till I saw that book
on
Design Patterns
·
· Score: 2
You probably think design meetings are a waste of time, too.
Well, with common nomenclature such as presented in
this book, those meeting are less of a waste of time.
And I find those little "meetings" that
occur in my head when I'm thinking about the design of
a program I'm working on are more productive, too.
-Ed
Re:Oh no, Yahoo's system works and is stable!
on
Yahoo Moving to PHP
·
· Score: 2
More likely new and printf.
At least in my experience, <cstdio> is
often one of the last vestiges of C to remain in C++
code.
It can be painful to go without printf-style formatting.
Who said it wasn't?
On the other hand, there are non-technical reasons
that may rationally be in his self-interest.
Using the same OS at work and at home is one
example.
The freedom to mix open-source and proprietary software
and legally redistribute the result is another.
These may not be reasons for you, but I don't think that
it's hard to imagine them being someone else's.
Actually, if you read Section 4 of that part of the
agreement ("# COLLECTED INFORMATION AND MODIFICATION OF SETTINGS") carefully you'll see
that it is pretty specific as to what information
is collected and uploaded -- just information
relevant to the installation and network configuration.
Nothing about whre you browse or other such information.
As other postings here make clear, Broadjump is
essentially an installer, and could be used to install
just about any software as well as setting up your
connection.
So you should read the rest of the agreement carefully
to see what the rest of its software load does.
(I skimmed through it and couldn't find anything
particularly suspicious, but you should check for
yousrself.)
It certainly would be a handy way to place spyware on
your system,
but as near as I can tell it isn't itself spyware.
-Ed
Re:Why BSD over Linux and History Clarifications
on
Overview of the BSDs
·
· Score: 5, Informative
Good grief; someone got it (mostly) right!
DEC's hardware was absolutely crucial to Unix's
emergence, even though DEC did damn near everything
to stop it.
I do have a few nits to pick, though, and a bit more info on BSD's contribution (specifically the 1.x and 2.x
series which ran on PDP-11 only):
PDP-11's supported 256KB of memory early on
due to the fact that the UNIBUS had 18 address lines.
The PDP-11/70 added another wider bus and so supported
more memory, as you say.
Although the PDP-11/40 and earlier supported only a
single 64KB address space, the PDP-11/45 supported
separate Data and Text (executable) spaces.
Most Unix installations were 11/45's or 11/70's, and so
supported this feature (which lead to the introduction of
"shared text" -- separate processes sharing a single copy of
executable code).
Saying that memory outside of 64KB was used as "fast
swap" is inaccurate, since it implies that processes were
copied to and from it; in fact, PDP-11's (from the '40 on)
had segmentation hardware which allowed that memory to be
mapped in without copying.
One of the things that BSD added to Unix on PDP-11's
was the ability to use its segmentation hardware to map
in and out parts of executables.
Although the granularity of 8KB segments tended to limit
this feature to separate phases of a program, it helped
soften the 64/64 barrier a bit on the code side.
Shared memory was another feature allowed by the
memory hardware that BSD took advantage of.
BSD also added a primitive (by later standards)
networking capability called, I believe, BerkNET.
A number of other features were added as well to PDP-11
BSD Unix along
with a lot of performance tuning and enhancement.
It wasn't unusual to have sixty people comfortably
sharing a PDP-11/70 doing software development and word
processing (and, of course, email and messaging).
Very little of what Berkeley added to PDP-11 Unix
survives.
This isn't surprising
given that a fair amount of it was designed
specifically to confront the 16-bit address limitation
in some way.
It's a bit amusing to hear some similar ideas being
discussed today (though more in Linux circles than BSD,
I think) for overcoming the 32-bit address limit.
(It's also a bit weird to think that if Moore's law
continues to hold, I'll probably live to see the same
thing happen at 64 bits!)
The VAX version of BSD (which was developed pretty much
separately -- the two overlapped by several
years) has direct influence on all BSD's
today, of course, and your post pretty covers its
development from Unix V32 through Ultrix.
-Ed
Re:Not an accurate comparison to Linux
on
Overview of the BSDs
·
· Score: 4, Informative
Current versions of BSD use GCC.
However, BSD was originally
developed using another compiler
(derived from Steve Johnson's PCC)
and if someone wanted to spend the
time, one of the BSDs could be moved to another
compiler today.
However, zealotry aside, there is no reason
to do so at this point;
The BSDs use GCC because it is the best free compiler
available for the job.
But the fact that BSD was already fairly mature
before it started using any
GNU software
distinguished it from Linux, which was
developed almost from the beginning
with GCC and other GNU tools.
Dictionaries don't have legal force.
The common-law definition of "theft" (which the
dictionary describes) was superceded long, long
ago, first by espionage laws and later by
trade secret laws.
The principles involved were well established
before computer programs even existed.
Slashdot Mirror
I've never seen someone fired for not having a degree unless they lied about it. But I've certainly seen people not hired in the first place for not having a degree -- which probably explains why some people wind up lying about it in the first place.
The BSD license isn't the same as public-domain. The only person who can change the license is the copyright holder. Sure, you can GPL your own changes to the BSD-licensed code, and distribute those changes as such. And you don't have to resistribute the original, since it wasn't GPL'd. But you can't redistribute the whole thing as GPL, because you don't have the copyright to the original.
This is probably the second of the most common misconception concerning of the BSD license. The most common misunderstanding is the idea that the BSD license allows people to "steal" the code and make it proprietary. That's false -- they are in the same position that you are. They can only make proprietary their changes and additions to the code. The original is as freely available as it ever was, as are all changes released under the original license. There is no added impetus to fork the BSD-licensed (and thus publically available) version.
I don't see much use in arguing over whether the GPL or the BSDL is more "free" -- such discussions tend to turn on semantic hair-splitting or contrived examples and probably have more to do with the personal inclinations of the people arguing than anything else. My own feeling is that both licenses have their place and there relative "freeness" depends upon the situation.
I appreciate the joke, but just to make a point: the lawyers are involved (and paid) whether a case ever is heard in a courtroom or not. And, in fact, an early trial might be quite a bit cheaper than all the filings and counterfilings that the lawyers wind up preparing.
You nailed this one! Murdoch is after market share, and will support whatever political viewpoint gives it to him. But I doubt if he has any much allegiance to any country -- even Australia -- only to himself.
It's Latin for "speak." Look up the English word "locution" (since I doubt most folks on this list have a Latin dictionary) and see.
Let's see...
Am I keeping score correctly here?
I'm sure there are a lot of firsts that could be added to this list. But I think the point is that you had better be sure what child you're talking about before asserting paternity.
One cure for the 100 ft cable is to use a second 100 ft cable -- to a pair of headphones. I'm surprised no one thought of that, or perhaps Jimi didn't like the idea of wearing cans [jargon for headphones] in concert.
Once upon a time (prior to 1978) there was no lseek() call in Unix. The value for the offset was 16 bits . Larger seeks were handled by using the different value for "whence" (the third argument to seek()) which causes seeks to occur in 512-byte increments. This resulted in a maximum seek of 16,777,216 bytes, with an arbitrary seek() often requiring two calls, one to get to the right 512-byte block and a second to get to the right byte within the block. (Thank goodness they haven't done any such silliness to break the 2GB barrier.)
When Research Edition 7 Unix came out, it introduced lseek() with a 32-bit offset. 2,147,483,648 bytes should be enough for anyone, hmmm? :-).
The FreeBSD folks have already done a considerable amount of work on this, even to the point of making time_t 64 bits for both kernel and userland and testing for issues. Enough is known that the main worry now is how to handle the change in ports, some of which need a fair amount of work to move away from 32-bit time_t. But at the rate things are going, I'd expect that they will make the transition to 64-bit time_t for FreeBSD 6.0. I've no idea how they will handle the legacy issues (ports and pre-6.0 binaries) though.
Exactly. And much as I hate to say it, this is why such hardware is inevitable. That's not to say that there won't be a thriving underground of hardware and software hackers who will work around most every DRM techniue that comes down the line; consider Satellite TV, for a contemporary example. But by the end of the decade hardware-based DRM will be nearly universal.
The RIAA and MPAA haven't produced enough solid evidence of economic loss to justify the enormous costs of the change to DRM hardware. But it's only a matter of time before such evidence is found -- or manufactured. And although I don't expect many people here to follow along, as more and more content is released in DRM-protected form, John Q. Public will eventually cave and acquire the necessary hardware (the cost of which will probably be subsidized by a "tax" on the exclusive content).
The problem isn't calling just calling fpathconf() repetitively. The problem is calling fpathconf() repetitively on a socket or other non-file (which would be a bug in itself). And by "repetitively" I mean at least 2,147,483,648 times on the same file descriptor for a system panic exploit, and exactly 4,294,967,295 times on the same file descriptor (followed by a close()) for the priviledge escalation exploit.
No network daemon that is part of the FreeBSD base system can be coerced into performing the necessary actions. Grep the source tree yourself (you'll only get a handful of hits) and examine the resulting files if you don't believe me. It's impossible to rule out everything in the ports collection (and the FreeBSD folks are careful not to make any claims regarding them) but it's hard to imagine creating an exploit of greater than theoretical importance using any network server.
This is a local vulnerability; it doesn't, in and of itself, make servers vulnerable. Even if someone has a local account on a system, it takes hours of CPU time to perform an exploit.
It looks like the bug (and the fix) were already announced (and committed to CVS) but that the possibility of using the bug in an exploit was not revealed until now (and might not even have been appreciated by the original reporter).
A lot of folks I know use Google to check out resumes and otherwise see what sort of projects a job candidate has been up to. People used to use DejaNews (back before it was "Google Groups") to do the same thing.
I'll not comment on whether I consider this ethical or not, but it makes a certain practical sense. But it makes a bit less sense for a date, however, given that the person's online persona may be under a different name, or may be partly or wholly an invention. Still, if I'm dating a (presumed) professional who is likely to have formal or informal writings that may be on the web, it would make sense to "check." I'd personally feel icky doing so, but others wouldn't have qualms...
I'd not call it is "forced" Object Orientation, but rather it is OO plus pre- and post-conditions in a methodology known as Design By Contract.
Change, and the new superseding the old, is what the Silicon Valley is all about. Yes, companies come and go, but it isn't the companies, per se, that make SV what it is. It's the human infrastructure, the critical mass of talent that is always ready to move on and create the next "great thing."
If someone posted this in the Slashdot Linux section (if it had one -- it doesn't need one, for reasons that are pretty obvious to all), we'd be virtually buried under a blizzard of "Be isn't Free Software/Be isn't Linux/How dare you compare Be with Linux" postings. Think about it& -- you know it's true. Of course, I'm going to get hammered with negative moderations for suggesting that Slashdot itself has joined with the BSD Is Dying troll in wanton BSD-bashing, but how else can we interpret this?
I try to be impartial; hell, I've run Linux since Yggsadril, and the computer nearest my left foot is running RedHat 7.2 (plus a customized kernel and security patches) while the one nearest my right foot runs FreeBSD 4.6-RELEASE. I read the LKML and a few freebsd-* mailing lists. My Alpha runs Linux, since Linux supports it better than any flavor of BSD. And I firmly believe that Linux is the best shot the free software community has against Microsoft. And, of course, Linux != Slashdot, so I'll continue to use and support it as much as I always have.
But now I have to say that the anti-BSD bias on Slashdot, which has been strongly hinted at before, has become starkly obvious. The mentality of many Slashdotters -- that Linux and BSD are somehow in competition rather than allies in the battle against Redmond -- seems to be infiltrating Slashdot itself. It's been subtle in the past, evidenced when major BSD events are simply ignored while random fluff gets reported. Now, it comes right out in the open.
I guess I've been in denial.
None of this is to be taken as slander against Be, which is about as fine a closed-source, not-really-free product as I've ever seen. It doesn't belong in the BSD section, however, and putting it here should be as much an insult against Be as it is against BSD.
Intel isn't exactly betting the farm on the PC market, either. Although Itanium isn't quite as do-or-die for Intel as the Hammer series is for AMD, they both know full well that making CPU's for PC's will be a shrinking part of their revenues. Making chips for servers is the market they are both shooting for. The margins are much higher and the market is actually growing at a good clip, unlike the PC market.
So I guess this may be bad news for folks who want really cheap bleeding-edge performance on their desktops. But business users don't need any more performance on the desktop than they already have, and even gamers are increasingly looking toward GPU's and not CPU's as the most important factor for performance in their systems. Intel and AMD are laying their bets in the server room.
Given that AMD already has the technology in hand to deliver more bang-per-buck than Itanium and with a smooth and solid migration path, this may be the most sensible move they've made in years.
I want something with genuine firepower. Not something that attempts to overcome burglars by giving them a case of the giggles.
You probably think design meetings are a waste of time, too. Well, with common nomenclature such as presented in this book, those meeting are less of a waste of time. And I find those little "meetings" that occur in my head when I'm thinking about the design of a program I'm working on are more productive, too.
More likely new and printf. At least in my experience, <cstdio> is often one of the last vestiges of C to remain in C++ code. It can be painful to go without printf-style formatting.
Who said it wasn't? On the other hand, there are non-technical reasons that may rationally be in his self-interest. Using the same OS at work and at home is one example. The freedom to mix open-source and proprietary software and legally redistribute the result is another. These may not be reasons for you, but I don't think that it's hard to imagine them being someone else's.
Actually, if you read Section 4 of that part of the agreement ("# COLLECTED INFORMATION AND MODIFICATION OF SETTINGS") carefully you'll see that it is pretty specific as to what information is collected and uploaded -- just information relevant to the installation and network configuration. Nothing about whre you browse or other such information.
As other postings here make clear, Broadjump is essentially an installer, and could be used to install just about any software as well as setting up your connection. So you should read the rest of the agreement carefully to see what the rest of its software load does. (I skimmed through it and couldn't find anything particularly suspicious, but you should check for yousrself.) It certainly would be a handy way to place spyware on your system, but as near as I can tell it isn't itself spyware.
Good grief; someone got it (mostly) right! DEC's hardware was absolutely crucial to Unix's emergence, even though DEC did damn near everything to stop it. I do have a few nits to pick, though, and a bit more info on BSD's contribution (specifically the 1.x and 2.x series which ran on PDP-11 only):
Very little of what Berkeley added to PDP-11 Unix survives. This isn't surprising given that a fair amount of it was designed specifically to confront the 16-bit address limitation in some way. It's a bit amusing to hear some similar ideas being discussed today (though more in Linux circles than BSD, I think) for overcoming the 32-bit address limit. (It's also a bit weird to think that if Moore's law continues to hold, I'll probably live to see the same thing happen at 64 bits!)
The VAX version of BSD (which was developed pretty much separately -- the two overlapped by several years) has direct influence on all BSD's today, of course, and your post pretty covers its development from Unix V32 through Ultrix.
Current versions of BSD use GCC. However, BSD was originally developed using another compiler (derived from Steve Johnson's PCC) and if someone wanted to spend the time, one of the BSDs could be moved to another compiler today. However, zealotry aside, there is no reason to do so at this point; The BSDs use GCC because it is the best free compiler available for the job. But the fact that BSD was already fairly mature before it started using any GNU software distinguished it from Linux, which was developed almost from the beginning with GCC and other GNU tools.
Dictionaries don't have legal force. The common-law definition of "theft" (which the dictionary describes) was superceded long, long ago, first by espionage laws and later by trade secret laws. The principles involved were well established before computer programs even existed.