Hardware/software boundaries need to be flexible
on
Soft Processors in FPGAs?
·
· Score: 3, Insightful
What I find intriguing about these systems is the possibility of starting with some custom hardware,
and lots of C code to perform logic, and interface
with the custom hardware.
Now, if I knew that interface was solid. I'd just want
a processor and a custom systems chip that did the
usual memory/peripheral interfacing and whatever
my special functions required. If I wasn't all that
worried about chip count I might even put the special
logic entirely on the memory bus as a seperate device.
But more frequently I have some complex logic that
I probably want to do in hardware, but I'm
not certain and I'm not 100% certain that the algorithm
is correct. For speed of development and refinement I
need to express that logic in a very conventional language such as C.
But planning ahead, I still define the function to fit within
a state machine, to have defined inputs and outputs, and
to avoid doing things that won't implement in hardware
very well (like complex wanderings through main memory)
I now have a module that is suitable to be implemented in hardware or software. Since I can do either, I take the first
draft in software.
By the time the code stabilizes I'll be confident that the
algorithm is correct and I'll know how important optimization is to the overall performance of the system.
I can now prioritize which modules are most worthy of
translating into hardware.
With a soft core I can shift resources between "software"
and "hardware" without having to re-layout the board,
design new pinouts, etc. In other words, I actually can
shift resources. Try getting a board layout changed on
a successful product just to optimize things sometime.
If the "hardware"/"software" boundaries ever stabilize
a lot, I can even consider going back to a conventional
processor core and full hardware solution. More likely
the market will demand totally new features by then.
"Quick & Dirty" is not necessarily the opposite of doing things properly.
Faced with a choice between "quick and dirty" versus
a long process that is not even ready to produce code
until everything is known, there isn't a company in the world who won't go with quick and dirty.
The long elaborate process doesn't really work anyway.
The world changes too quickly.
What you need is a methodology which emphasizes
development in stages. XP (Extreme Programming)
and Feature Driven Design (a variant of UML) are two
examples.
The important thing is to identify your fundamental interfaces, make sure those are right. Document them. And then feel free to code each and every component as "quick and dirty" as you ever imagined.
If you did the first part right, you can replace components later, add new components, etc.
If you didn't document your interfaces well... you've just delayed the failure of the project through absurd amounts of overtime. You have zero chance of longterm success.
It isn't even necessary to always have a grand master plan.
Well documented simple interfaces can frequently be extended in ways that weren't anticipated
when they were first created. But you have to focus on the interfaces - that's what allows for evolution.
The most obvious example of this is the Internet
itself. The OSI stack was trying to do things "thoroughly",
IP just wanted to be "flexible". Flexible can be developed cheaply, and unlike either pedanticly thorough methodologies or complete anarchy, has a chance to
build itself up one useful piece at a time.
A Mac OS X process has a 4 GB virtual memory map.
Any page could be mapped anywhere within the
physical memory, so there can be more than 4 GB
in use. But no single map can directly access more
than 4 GBs at a time.
Maps have no problem with this. Depending on the exact mapping system used by an OS the entry in the map table is either a 32-bit page address, or a 64-bit physical address.
x86 "hybrid" operating systems had to mix segmented mode with flat addresses. This is a very complex problem.
OS/2 had a more systematic approach to it, and even it
had problems.
Going from a virtual 32 bit flat address space to a flat address space that can be 32 bit or 64 bit depending
on the user process is far simpler.
It is also not that important until individual processes require more then 31 bits of address space.
Being able to support more than 32 bits of physical
address space is a more imminent problem. But given
the specs on the latest G5 machines it is obviously
solved already.
The objective of every broadcaster, commercial and non-commercial, is to attract and keep an audience. If the station puts being independent ahead of playing something the audience likes, it will flounder.
Great idea. It would even work if every radio station were independently owned and
operated, trying to maximize its revenue in honest
competition.
You need to review some recent FCC "rulings" (i.e. adminstrative acts of sabotage against the spirit
of the law that they are supposed to be enforcing).
If there is no malice, and no callous disregard for the property rights of others, then the only corrective
action that could be demanded would be
removal of the infringing code: something the entire Linux community has already offered to do, but can't because the allegedly infringing lines have not been publicly identified.
perhaps pay royalties on the portion of Linux revenues
that those lines of code represented: Let's see 80 lines over how many was that?
Seriously, go look up some cases on inadvertent quoting without citation. You won't find any billion dollar judgements.
I am fully in favor of music creators being able to
collect payment for their work. However, there
needs to be some fairness between over-the-
air broadcasters and over-the-net webcasters.
I fail to see any reason why the artist or label
is entitled to more payment because the "broadcaster"
is using the Internet to deliver the music.
The Anti-trust act may be fully applicable if the
real point is that the RIAA and record labels prefer
the over-the-air broadcasters (with heavily
concentrated ownership) to the truly independent webcasters.
And anyone who believes that radio broadcasters
exercise "independent" judgement in their selection
of music obviously never listens to the radio.
If the intent is for the laptop to match the deployment environment, then he should be buying the same
crappy laptop(s) that the customers will use.
If the intent is to test stuff that will be run in a
general Windows environment, then emulation
is a very valid testing strategy. For one thing it
makes it very possible to *switch* between multiple
Windows versions quickly. Real machines don't do
that anywhere near as well.
If the intent is to target a Linux/Unix/BSD type
environment, then you shouldn't care what the
processor is anyway. You should be developing
for multiple architectures, as the prior post stated.
If you are testing specific peripherals,
that is different. But then you should be matching
the target environment more than a laptop will
probably allow anyway.
When making statements about an OS's bitsize, the real issue is what size are the pointers that it allows users
to deal with as flat addresses.
In that sense, AmigaDos was at least 24-bit from
the very beginning. I don't recall when it correctly
dealt with the full 32 bits. But I don't believe it
ever had any constructs that forced memory to
be be dealt with in 64 KB chunks -- which is what
I would expect of a "16 bit" OS.
If you are just targetting Intel processors with
open source tools, you shouldn't have any problems.
If you need to target a non-gnu platform, however,
well then you need a really good laptop to compensate
for the hassles.
I was fairly satisfied with a Sony VAIO that a previous
employer insisted on paying too much for. (I submitted
the specs for an iBook, but they insisted on spending
more money) Of course it not only cost more, but ended up needing repairs more often.
I bought an iBook on my own, but really haven't seen
a PC laptop that I would buy on my own yet.
My advise is to concentrate on the features you most
like in a PowerBook/iBook. Is it the display? The ports?
General durability? Running a GUI desktop and a Unix
shell at the same time?
If the latter is a factor, as in you might want to do some
network analysis in the field, then you want to pre-validate
that the laptop you're looking at can be partitioned and
dual-booted with either Linux or BSD.
I'm mostly going on what various patent lawyers had told me on the need to beef up claims, based on the theory and actual wording of patent laws. I can recall them citing
some patents that the company had rejected in the 70s
that would have clearly been accepted currently.
Most importantly, I can read the patents that are issued.
None of them would pass the criteria I was given on what
he had to establish in order to file a patent. Alacritech, for
example was granted a claim that would seem to apply
to any method of placing a TCP engine on a co-processor
card. Now Alacritech has indeed come up with innovative
specific methods for doing this, but the *desirability* of
doing this was painfully obvious to anyone.
Anyone can see that a car that got 500 MPG would be neet.
And you should be able to patent your solution for doing so. But all too many of these patents include a first claim
to the effect of "A method by which an automative vehicle
is equipped to obtain milage in excess of 500 miles per gallon."
For SCO to prevail it will have to establish that it owned
the code, and that it was included in Linux distributions
with malice and/or a callous disregard for the property
rights of the code's true owners, but that SCO's "accidental" release of the same code under the GPL was not deliberate
and shouldn't be held against it.
It seems to me that SCO was in a far better position to
recognize that the code being distributed as part of
Caldera was in fact part of SCO's property than it was
for other Linux distributors who did not have access
to that confidential code.
With modern hardware there is no difference.
A "hardware" implementation performs a sequence of
logical operations that have been arranged in an
innovative way to produce a valuable result. A
software implementation does the same thing.
In either case, the essential innovation of having
researched a method of sequencing and controlling
the individual steps can be easily stolen and given
a totally new representation. Copyright is clearly
not suitable protection.
The emphasis has to be on ensuring that it is
the innovative cominbation that is being patented,
not the valuable result, and that it is indeed innovative.
Removing the need to prove true innovation makes
the patent game a race to file a claim.
And as any/. reader should know, the "first post"
seldom contributes to the process.
The article clearly points out that the problem is
in patenting business procedures, rather than true
inventions.
If you review the history, there were two changes
in the recent interpretation of patent law.
A presumption was created that an invention was innovative, and that it was almost up to the examiner to
prove that it was not. Before the 80s patents
were rejected on the sole grounds that while the applicant
may have been the first to develop the technique, anybody
researching such a product would have done the same thing. We need to get back to that interpretation.
Software patents were allowed. More precisely the
artificial preference for solutions realized in hardware
was removed.
The problems are related to granting patents for things
that are a) not specific solutions, merely statement of problems, and b) obvious.
So I believe we need to restore the orignal presumption
that a proposed patent is not sufficiently innovative. The other thing that has changed since when the patent system
was mostly considered to be working is that the world has
sped up. A 17 year period may have made sense in the
19th century, it is way too long for the 21st.
But none of those are arguments against the inherent
ideas of patents. Citing the current abuses of the patent
system as an arguments against patents in general is
like citing Windows 95 as an argument against having
an OS.
Yes..NET uses XML. Use of XML as peer-to-peer
protocol remains, IMHO, a very stupid idea. It is
very nice for documents. But binary encoding of
wire messages, such as is done by CORBA, is
clearly superior. I remain opposed to definition
of "new" XML services that merely duplicate
existing CORBA and/or RPC solutions with
the sole benefit of consuming more bandwidth
while circumventing network security by pretending
to be a "web" protocol.
But saying that.NET uses XML is like saying
NFS uses RPC. Neither is complete documentation.
I found available open specs on *how*.NET uses XML,
and how to generate your own compatible messages,
to be conspicuously absent, or at the minimum insufficiently indexed and highlighted.
Clearly, the developers of the documetation did not
believe that "typical users" would have to be "burdened"
with these details. (Which, I suspect, is the most charitable
interpretation likely to be found on/. for these actions.).
Personally, I do not like the "convenience" of being locked
into a single solutions provider.
To clarify: my evaluation was as an architect examing
the inherent definitions of the different runtime
environments. In my opinion, a.Net runtime
environment should be able to approach "native
code" efficiency more readily than a JVM.
That said, keep in mind that most applications
that require portable code are more bound by network
interactions and/or the speed of supporting libraries.
A numerically-intensive application is more likely to
be dependent on the quality of the run-time library.
That's something you have to evaluate each specific
virtual machine on.
On a point-by-point comparison,.Net frequently is superior to Java. It falls short on the fundamental
points you raise: interoperability, and more importantly
seperability. Using Java you know exactly which technologies you are embracing, and which you
are leaving out. Java/XML, Java/RMI, Java/Corba...
It's all your decision.
The other feature that.Net has is superior native execution,
it was designed to be translated to native code. The.net
virtual machine is better defined than the JVM is. But I
agree that on whole, the tradeoff is not worthwhile.
Three years in and I believe it is fair to say that most
people do not understand exactly what.Net is --
other than a vague "trust me" monolithic solution.
Which I believe is the core of its problem. While there
are some fools who will buy anything that fill in
the name of their favorite supplier offers, more
of the market wants to make decisions for themelves.
From the little I've had time to study.Net, there were
a few aspects of it that were indeed superior to what
had proceeded it on the market. But the information
to make a cohesive strategy was just missing. What
if I liked the characteristics of the run-time engine,
but needed to stick with CORBA interfacing?
The most telling flaw in the strategy, for me, was
that you could find entire racks of books on.Net.
But absolutely none that explained the basic wire
protocols used. They were all "How to Program a.Net application inside one box using language Y".
When I'm designing a system, the language used
on each box is the last detail that I
consider. I want to understand the interactions
of the remote systems, how dependent they
are on each other, how they evolve seperately,
how the failure of one will affect the others, etc.
The point of Fair Use is to allow a work to be discussed
or referenced without obtaining permission, as long as
it is done in a way that does not diminish the value of
the original work.
Hence a thumbnail hints at what the whole picture
looks like, and might even inspire you to buy the
full resolution picture. A 30 second clip gives you
a sense of the song, without giving the song away.
But it is not a right to steal by downsampling or
slicing into pieces which gasp can be
put back together again.
Fair Use has an important role in the exchange of
information. Don't muddy it up as some flimsy
excuse for theft.
An excellent source on the prevelance of false convictions
can be found at www.innocenceproject.org.
However this page shows that faulty
DNA evidence is positively rare as a factor in false
convictions, at least so far.
But if you really have doubts about the ability of
police to convict innocent poor people then you haven't
been following the news. Illinois had a stretch where
more people on Death Row were exonerated
than were actually executed. By anyone's definition
that is a very troublesome error rate.
And entering your home without your permission
and stealing the pile of currency you left in plain
sight would be against the law too.
But that doesn't mean that its a good idea to leave
currency lying around in plain sight in unlocked rooms.
At the minimum someone getting your POP password
can read and delete your email. There is a good chance
that they will be able to send email as you was well.
Conference attendees are likely to be of above
average importance to their firms. Use of unencrypted
email in a public forum like that is simply negligent.
Agreed. Anytime you are checking your email
on the road it should be secure. ssh tunneling
is one method, secure webmail is another.
What amazes me is that so few firms understand
that their "road warriors" are their weakest link
in their security. You frequently see firms where
engineers are told they cannot work from home,
even with ssh tunneling, "for security reasons",
but the companies' road warriors are zipping in
and out of airports with detailed business plans
and spreadsheets sitting on their unsecured laptops.
Hint to sysadmins, if you're letting them fetch their
mail over a clear connection, you'd probably let
someone else pretending to be them send email
through the company mail server.
Slashdot Mirror
What I find intriguing about these systems is the possibility of starting with some custom hardware, and lots of C code to perform logic, and interface with the custom hardware.
Now, if I knew that interface was solid. I'd just want a processor and a custom systems chip that did the usual memory/peripheral interfacing and whatever my special functions required. If I wasn't all that worried about chip count I might even put the special logic entirely on the memory bus as a seperate device.
But more frequently I have some complex logic that I probably want to do in hardware, but I'm not certain and I'm not 100% certain that the algorithm is correct. For speed of development and refinement I need to express that logic in a very conventional language such as C.
But planning ahead, I still define the function to fit within a state machine, to have defined inputs and outputs, and to avoid doing things that won't implement in hardware very well (like complex wanderings through main memory)
I now have a module that is suitable to be implemented in hardware or software. Since I can do either, I take the first draft in software.
By the time the code stabilizes I'll be confident that the algorithm is correct and I'll know how important optimization is to the overall performance of the system. I can now prioritize which modules are most worthy of translating into hardware.
With a soft core I can shift resources between "software" and "hardware" without having to re-layout the board, design new pinouts, etc. In other words, I actually can shift resources. Try getting a board layout changed on a successful product just to optimize things sometime.
If the "hardware"/"software" boundaries ever stabilize a lot, I can even consider going back to a conventional processor core and full hardware solution. More likely the market will demand totally new features by then.
"Quick & Dirty" is not necessarily the opposite of doing things properly.
Faced with a choice between "quick and dirty" versus a long process that is not even ready to produce code until everything is known, there isn't a company in the world who won't go with quick and dirty.
The long elaborate process doesn't really work anyway. The world changes too quickly.
What you need is a methodology which emphasizes development in stages. XP (Extreme Programming) and Feature Driven Design (a variant of UML) are two examples.
The important thing is to identify your fundamental interfaces, make sure those are right. Document them. And then feel free to code each and every component as "quick and dirty" as you ever imagined.
If you did the first part right, you can replace components later, add new components, etc.
If you didn't document your interfaces well... you've just delayed the failure of the project through absurd amounts of overtime. You have zero chance of longterm success.
It isn't even necessary to always have a grand master plan. Well documented simple interfaces can frequently be extended in ways that weren't anticipated when they were first created. But you have to focus on the interfaces - that's what allows for evolution.
The most obvious example of this is the Internet itself. The OSI stack was trying to do things "thoroughly", IP just wanted to be "flexible". Flexible can be developed cheaply, and unlike either pedanticly thorough methodologies or complete anarchy, has a chance to build itself up one useful piece at a time.
A Mac OS X process has a 4 GB virtual memory map. Any page could be mapped anywhere within the physical memory, so there can be more than 4 GB in use. But no single map can directly access more than 4 GBs at a time.
Maps have no problem with this. Depending on the exact mapping system used by an OS the entry in the map table is either a 32-bit page address, or a 64-bit physical address.
x86 "hybrid" operating systems had to mix segmented mode with flat addresses. This is a very complex problem. OS/2 had a more systematic approach to it, and even it had problems.
Going from a virtual 32 bit flat address space to a flat address space that can be 32 bit or 64 bit depending on the user process is far simpler.
It is also not that important until individual processes require more then 31 bits of address space. Being able to support more than 32 bits of physical address space is a more imminent problem. But given the specs on the latest G5 machines it is obviously solved already.
Great idea. It would even work if every radio station were independently owned and operated, trying to maximize its revenue in honest competition.
You need to review some recent FCC "rulings" (i.e. adminstrative acts of sabotage against the spirit of the law that they are supposed to be enforcing).
If there is no malice, and no callous disregard for the property rights of others, then the only corrective action that could be demanded would be
Seriously, go look up some cases on inadvertent quoting without citation. You won't find any billion dollar judgements.
I am fully in favor of music creators being able to collect payment for their work. However, there needs to be some fairness between over-the- air broadcasters and over-the-net webcasters.
I fail to see any reason why the artist or label is entitled to more payment because the "broadcaster" is using the Internet to deliver the music.
The Anti-trust act may be fully applicable if the real point is that the RIAA and record labels prefer the over-the-air broadcasters (with heavily concentrated ownership) to the truly independent webcasters.
And anyone who believes that radio broadcasters exercise "independent" judgement in their selection of music obviously never listens to the radio.
If the intent is for the laptop to match the deployment environment, then he should be buying the same crappy laptop(s) that the customers will use.
If the intent is to test stuff that will be run in a general Windows environment, then emulation is a very valid testing strategy. For one thing it makes it very possible to *switch* between multiple Windows versions quickly. Real machines don't do that anywhere near as well.
If the intent is to target a Linux/Unix/BSD type environment, then you shouldn't care what the processor is anyway. You should be developing for multiple architectures, as the prior post stated. If you are testing specific peripherals, that is different. But then you should be matching the target environment more than a laptop will probably allow anyway.
When making statements about an OS's bitsize, the real issue is what size are the pointers that it allows users to deal with as flat addresses.
In that sense, AmigaDos was at least 24-bit from the very beginning. I don't recall when it correctly dealt with the full 32 bits. But I don't believe it ever had any constructs that forced memory to be be dealt with in 64 KB chunks -- which is what I would expect of a "16 bit" OS.
If you are just targetting Intel processors with open source tools, you shouldn't have any problems. If you need to target a non-gnu platform, however, well then you need a really good laptop to compensate for the hassles.
I was fairly satisfied with a Sony VAIO that a previous employer insisted on paying too much for. (I submitted the specs for an iBook, but they insisted on spending more money) Of course it not only cost more, but ended up needing repairs more often.
I bought an iBook on my own, but really haven't seen a PC laptop that I would buy on my own yet.
My advise is to concentrate on the features you most like in a PowerBook/iBook. Is it the display? The ports? General durability? Running a GUI desktop and a Unix shell at the same time?
If the latter is a factor, as in you might want to do some network analysis in the field, then you want to pre-validate that the laptop you're looking at can be partitioned and dual-booted with either Linux or BSD.
Imagine having to pay to obtain access to something you must comply with.
Only standards bodies are allowed to pull nonsense like that.
Now if we can only get some municipality to legislate compliance...
Um, to be fair, Java had a healthy dose of hype too.
Agreed. It's the implementation of the patent process that is flawed. Not the concept, or even necessarily the laws as currently written.
I'm mostly going on what various patent lawyers had told me on the need to beef up claims, based on the theory and actual wording of patent laws. I can recall them citing some patents that the company had rejected in the 70s that would have clearly been accepted currently.
Most importantly, I can read the patents that are issued. None of them would pass the criteria I was given on what he had to establish in order to file a patent. Alacritech, for example was granted a claim that would seem to apply to any method of placing a TCP engine on a co-processor card. Now Alacritech has indeed come up with innovative specific methods for doing this, but the *desirability* of doing this was painfully obvious to anyone.
Anyone can see that a car that got 500 MPG would be neet. And you should be able to patent your solution for doing so. But all too many of these patents include a first claim to the effect of "A method by which an automative vehicle is equipped to obtain milage in excess of 500 miles per gallon."
For SCO to prevail it will have to establish that it owned the code, and that it was included in Linux distributions with malice and/or a callous disregard for the property rights of the code's true owners, but that SCO's "accidental" release of the same code under the GPL was not deliberate and shouldn't be held against it.
It seems to me that SCO was in a far better position to recognize that the code being distributed as part of Caldera was in fact part of SCO's property than it was for other Linux distributors who did not have access to that confidential code.
With modern hardware there is no difference. A "hardware" implementation performs a sequence of logical operations that have been arranged in an innovative way to produce a valuable result. A software implementation does the same thing.
In either case, the essential innovation of having researched a method of sequencing and controlling the individual steps can be easily stolen and given a totally new representation. Copyright is clearly not suitable protection.
The emphasis has to be on ensuring that it is the innovative cominbation that is being patented, not the valuable result, and that it is indeed innovative.
Removing the need to prove true innovation makes the patent game a race to file a claim.
And as any /. reader should know, the "first post"
seldom contributes to the process.
The article clearly points out that the problem is in patenting business procedures, rather than true inventions.
If you review the history, there were two changes in the recent interpretation of patent law.
The problems are related to granting patents for things that are a) not specific solutions, merely statement of problems, and b) obvious.
So I believe we need to restore the orignal presumption that a proposed patent is not sufficiently innovative. The other thing that has changed since when the patent system was mostly considered to be working is that the world has sped up. A 17 year period may have made sense in the 19th century, it is way too long for the 21st.
But none of those are arguments against the inherent ideas of patents. Citing the current abuses of the patent system as an arguments against patents in general is like citing Windows 95 as an argument against having an OS.
Yes. .NET uses XML. Use of XML as peer-to-peer
protocol remains, IMHO, a very stupid idea. It is
very nice for documents. But binary encoding of
wire messages, such as is done by CORBA, is
clearly superior. I remain opposed to definition
of "new" XML services that merely duplicate
existing CORBA and/or RPC solutions with
the sole benefit of consuming more bandwidth
while circumventing network security by pretending
to be a "web" protocol.
But saying that .NET uses XML is like saying
NFS uses RPC. Neither is complete documentation.
I found available open specs on *how* .NET uses XML,
and how to generate your own compatible messages,
to be conspicuously absent, or at the minimum insufficiently indexed and highlighted.
Clearly, the developers of the documetation did not believe that "typical users" would have to be "burdened" with these details. (Which, I suspect, is the most charitable interpretation likely to be found on /. for these actions.).
Personally, I do not like the "convenience" of being locked
into a single solutions provider.
To clarify: my evaluation was as an architect examing the inherent definitions of the different runtime environments. In my opinion, a .Net runtime
environment should be able to approach "native
code" efficiency more readily than a JVM.
That said, keep in mind that most applications that require portable code are more bound by network interactions and/or the speed of supporting libraries.
A numerically-intensive application is more likely to be dependent on the quality of the run-time library. That's something you have to evaluate each specific virtual machine on.
On a point-by-point comparison, .Net frequently is superior to Java. It falls short on the fundamental
points you raise: interoperability, and more importantly
seperability. Using Java you know exactly which technologies you are embracing, and which you
are leaving out. Java/XML, Java/RMI, Java/Corba...
It's all your decision.
The other feature that .Net has is superior native execution,
it was designed to be translated to native code. The .net
virtual machine is better defined than the JVM is. But I
agree that on whole, the tradeoff is not worthwhile.
Three years in and I believe it is fair to say that most people do not understand exactly what .Net is --
other than a vague "trust me" monolithic solution.
Which I believe is the core of its problem. While there are some fools who will buy anything that fill in the name of their favorite supplier offers, more of the market wants to make decisions for themelves.
From the little I've had time to study .Net, there were
a few aspects of it that were indeed superior to what
had proceeded it on the market. But the information
to make a cohesive strategy was just missing. What
if I liked the characteristics of the run-time engine,
but needed to stick with CORBA interfacing?
The most telling flaw in the strategy, for me, was that you could find entire racks of books on .Net.
But absolutely none that explained the basic wire
protocols used. They were all "How to Program a .Net application inside one box using language Y".
When I'm designing a system, the language used on each box is the last detail that I consider. I want to understand the interactions of the remote systems, how dependent they are on each other, how they evolve seperately, how the failure of one will affect the others, etc.
The point of Fair Use is to allow a work to be discussed or referenced without obtaining permission, as long as it is done in a way that does not diminish the value of the original work.
Hence a thumbnail hints at what the whole picture looks like, and might even inspire you to buy the full resolution picture. A 30 second clip gives you a sense of the song, without giving the song away.
But it is not a right to steal by downsampling or slicing into pieces which gasp can be put back together again.
Fair Use has an important role in the exchange of information. Don't muddy it up as some flimsy excuse for theft.
An excellent source on the prevelance of false convictions can be found at www.innocenceproject.org.
However this page shows that faulty DNA evidence is positively rare as a factor in false convictions, at least so far.
But if you really have doubts about the ability of police to convict innocent poor people then you haven't been following the news. Illinois had a stretch where more people on Death Row were exonerated than were actually executed. By anyone's definition that is a very troublesome error rate.
And entering your home without your permission and stealing the pile of currency you left in plain sight would be against the law too.
But that doesn't mean that its a good idea to leave currency lying around in plain sight in unlocked rooms.
At the minimum someone getting your POP password can read and delete your email. There is a good chance that they will be able to send email as you was well.
Conference attendees are likely to be of above average importance to their firms. Use of unencrypted email in a public forum like that is simply negligent.
Agreed. Anytime you are checking your email on the road it should be secure. ssh tunneling is one method, secure webmail is another.
What amazes me is that so few firms understand that their "road warriors" are their weakest link in their security. You frequently see firms where engineers are told they cannot work from home, even with ssh tunneling, "for security reasons", but the companies' road warriors are zipping in and out of airports with detailed business plans and spreadsheets sitting on their unsecured laptops.
Hint to sysadmins, if you're letting them fetch their mail over a clear connection, you'd probably let someone else pretending to be them send email through the company mail server.