Yes, it's a crude experiment, based on usability[...]
No, it's not based on usability. If it were, you would be
asking questions like, "Does it feel slow?" and "Can you do useful
work with it." Your experiment is based on examining the contents of/proc/meminfo.
Actually, I have no idea what your experiment is supposed to prove,
since you never say anything about how you interpreted the contents of/proc/meminfo. That pseudo-file gives you a lot of information about
the system's memory use and you never said which parts were
relevant and how.
What I am saying is that a modern Linux distribution has some very
heavy system requirements, and they have jumped up an awful lot from
previous distributions as little as six years ago.
I'm not disputing that. Although now that you bring it up, I'd
like to point out that this is irrelevant. If you're going to build a
$100 laptop, you're going to want to put together your own Linux
distribution as well, so the real question is, "How small can you make
this distribution and have it still be useful?" Since Redhat doesn't
even try to keep Fedora small, its size isn't useful in this
discussion.
Maybe if you looked at the sizes of floppy- and flash-based
distributions, you'd have a point, but the sizes of mainstream
distributions are irrelevant.
Get over it, get a life. There's more to the world than Linux -
it's a tool, nothing more, and nothing less. If you can't take
criticism of Linux, then maybe you should wear ear muffins:-)
Linux criticism I'm fine with. It's fuzzy thinking that grates on
me. Also, I tried getting one of those "life" things but I find it
interferes too much with my Slashdot posting.
I may be wrong about this, but I'm pretty sure that's a bad way to measure memory usage. Modern Linux kernels just continue to keep stuff in memory until something else needs the RAM. The question is not how much RAM the kernel is using right now but how well it can juggle resources when they're limited. You can't figure that out without doing actual experiments on limited hardware.
A quine is simply a program which, when run, prints out its own source code.
In my previous post, I sort of overloaded this a bit to mean a program that prints out its own executable. (Which, I suppose, would still be source code if you're insane enough to hand-assemble the thing with a hex editor.)
Actually, I went a bit further than that. My hypothetical virus is a program that can output two programs (a Windows binary and a Linux binary), each of which can also output both programs.
As for having a dual-platform binary, Linux has a mechanism to let you define arbitrary interpreters (or loaders?) for binary files. This would let you, for example, set up the kernel to run the Java VM on a JAR file whenever you set the execute flag on the JAR and run it as a program. Presumably, you could use this mechanism to run Windows binaries as well. You could put the Linux code in a dead section of the Windows executable, then set some harmless flag in the header. Windows would ignore the flag but you'd set up a special loader in Linux to check for it and if present, jump to the Linux part of the executable.
They've figured out how to hack together a fat binary.
It's possible that there's some sequence of bytes such that each
operating system interprets it as the header for some kind of
executable file and the Linux stuff is ignored by the Windows
loader and vice versa. You'd end up with a Linux program, a
Windows program and a special little bit of code that jumps to one
or the other depending on what OS there is, all in one big
executable.
(This would actually be pretty cool for non-malicious code as
well. I'm not sure if it would be useful but it'd be cool.)
Maybe the virus spreads via buffer overflow. In this case, it can
bypass the differences in loadfile format. Instead of loading
from disk, it would load itself into a target program's RAM over
the network via that buffer overflow, then take over.
For this to work, it would need to contain multiple exploits for
various different bugs in various networked programs, but that's
been done.
Of course, to do anything even remotely useful (in the virus sense
of the word) after that, it would need to be able to use operating
system resources. (The article seems to say that it doesn't use
OS resources, but if that's the case, how can it spread? Disk and
network access have to go through the OS.) The only way I can
think of is for each system call routine to test for OS type and
do the Linux thing or the Windows thing, depending.
You might be able to simplify that by dynamically calling the
standard C library but even then, calling conventions and
structure layouts are going to be different and that's going to
make things really complicated.
Maybe the virus is a quine
but capable of producing a Windows or Linux version of itself.
That would be relatively easy to do--just tack on the Linux and
Windows parts as data.
For that to work, though, the virus would need to know in advance
what platform its target is running. That's tricky but not
impossible.
Hmmm. Alternately, you could combine this with the previous
method, putting together a polymorphic program that's just smart
enough to identify the OS it's running under, then branch to
either the Linux or Windows version of itself.
That sounds reasonable to me.
All that being said, I doubt that this is going to make it
into the wild, if for no other reason than it's a huge amount of extra
work to do just to get a five percent increase in penetration. And
that doesn't even begin to take into account the differences in the
various OSs' security.
The FA is a bit light on hard details, I noticed. This looks like a
publicity stunt more than anything else.
Both Eric Sink (the
founder of SourceGear) and
Joel Spolsky seem to think so. (You'll have to search for the
relevant articles yourself--I'm not going to dig through years worth
of archives for you.)
Their thinking is:
If the guy in charge doesn't understand the technology, he
(or she) will make bad strategy decisions. Spolsky's example is John
Scully's decision to build a device that recognized handwriting (which
is impossible, or at least very hard) vs. Bill Gates' asking his
developers to write a reusable rich text edit control (which Microsoft ended up reusing for everything).
At the small company level, business stuff (aside from law and
accounting, both of which can be outsourced) tends to be easy enough
that a geek can learn it without too much trouble. Therefore (says
Eric Sink), it's a better use of money to get technical people than
business people.
On the other hand, the business guy is your friend and anyway,
he's willing to talk to investors and answer the phone during the
daytime (I'm assuming) so he's probably worth keeping around.
I think that what I'd do in your situation is give the business
guy the job of CEO but retain a 51% ownership of the company. That
lets him do the day-to-day business stuff and give the people he talks
to a sense that they're talking to the guy in charge while at the same
time letting you set him right if he tries to do something stupid.
Disclaimer: I have no actual experience in this. I'm just makin'
stuff up.
So, yes, there are many good reasons to choose Eiffel over other OO languages.
Let me add another one. Eiffel has memory safety and garbage collection and also compiles your source code into standalone binary executables. I've had a lot of trouble finding a language that I can use for boring projects that combines those properties. Everything seems to either require a bunch of runtime files, has no user base or is C/C++. Eiffel appears to be a decent alternative.
Ah, yes, Microsoft Visual English++. Here are a couple of important MSVE++ words that you may have heard (with their definitions):
Innovation
Cloning or buying an existing product, making incremental improvements to it and selling the result at price low enough to kill or marginalize the competition.
Impossible
We currently don't have a product that solves that problem.
Just to add more fuel to the fire, I should point out that this isn't always the case. And since that bald assertion won't fly, I'll support it with a baseless anecdote:
A friend of mine who works at a large IT installation recently told me that he'd recommended using Oracle instead of Postgres because it was cheaper. Oracle's lower hardware requirements more than made up for the cost of the license in that particular situation.
Now, I believe it because I trust the people involved but I have no real motivation to do the research myself. I'm also pretty sure that you wouldn't find that unless you had the sort of requirements that make Database vendors salivate. Still, it shows that open-source isn't always the cheapest solution.
I've been fortunate enough to never have had to work in a
seriously disfunctional workplace. However, from what I've read, the
best way to combat this sort of management style (or at least to avoid
getting shafted when they start handing out blame) is to make sure you
have everything in writing and then make sure you have a
complete set of copies.
Every time you have some objection to a decision, inform the
manager of this in writing as a memo or email. If your company has
some kind of system that automatically archives all project-related
communication, that's ideal. But every time the manager asks you to
do something that you consider a bad idea, you should make sure that
there are records of
Your objections to the order.
Your manager's admitting to having read your objections and
deciding to do it anyway.
Remember to be polite and clear. Your intent should be to inform
the manager of potential pitfalls with this decision, not to
criticize. Any sort of rudeness will get you fingered as a malcontent
and not a team player and it's vital that you come across as a perfect
little cog in these records.
Finally, make sure you have your own copies of all of this
communication and that you them it at home, out of reach of any
possible after-hours doctoring.
Disclaimer: I've never yet had to do this, but I've read about it
on USENET. Your mileage may vary.
Correct me if I'm wrong here, but what they're going to be doing is
implementing a system where people who pay AOL a fee can bypass their
spam filters, right?
So what this means is that:
AOL users will lose more legitimate email to false positives.
AOL users will still get spam.
Why don't they just start throwing bricks through their customers'
windows? It'd be a much more efficient way of pissing them off.
There's also a Wikinews article about it here. It looks like most of the content of the BBC news article comes from it. BoingBoing also talks about it, pointing out that they did (gasp) investigative reporting. That article is here.
I have a bit of experience with both Tck/Tk and Visual Basic 5.
Here's what I think:
Tcl/Tk is great for dashing off little graphical apps that do
stuff. I once wrote a fully-functional GUI front end for "cdplayer"
in 8 lines and ten minutes. It's the easiest tool I've ever used for
hand-coding GUIs but you can also get GUI builders for it.
Good things:
Cross platform, free and open-source
Well documented in ways that don't assume you're an idiot.
It's really, really easy to get a GUI up and running.
It's extremely flexible. You can override nearly every
aspect of a widget, add new behaviour and even write your own widgets
in Tcl. I've seen WinAmp-style user interfaces in Tcl/Tk
applications.
It's simple. Most Windows-based development tools I've
used have zillions of functions, classes and datatypes, far more than
you could ever grok. Tcl/Tk is small enough that I could still get a
sense of knowing how everything worked.
Tcl, for all its wierdness, is an incredibly flexible language.
You can write your own control structures in it and you can create
multiple interpreters so that your Tcl/Tk application can provide Tcl
as a scripting language while protecting the app's internals from
scripts.
It's got a really simple C API. C code can call Tcl code which
calls C code which calls Tcl code and so on.
It's interactive. You type in and evaluate expressions on the command line and even build GUI controls that way.
Bad things:
It's ugly, at least out of the box. It's possible to make your
app look nice (and maybe even Windows-native) but it requires a lot of
tinkering to do.
Tcl isn't really designed for developing large programs. (I
haven't tried [incr Tcl] though--that might be better). It'll do in a
pinch (and my app grew to some 13000 lines of Tcl without getting
unmanageable) but lack of types and the error/catch exception
mechanism became a hassle after a while.
There were a few Windows things that I couldn't do without
writing a C routine to do it and linking it in.
No debugger. You're stuck using printf^Wputs statements.
If I were going to write a large or complex Windows app today, I'd
probably write the interface in Tcl/Tk and the actual complex stuff in
C.
As for Visual Basic, I didn't really use it enough to have an
informed opinion. When I used it, I found that it was really
easy to create a GUI but the IDE became irritating to use once I
needed to write larger amounts of actual code. I also found the help
reader annoying (but this was version 5--they may have improved since)
and the documentation condescending.
It worked well as long as I didn't try anything too unusual. I
don't think I could do Tcl/Tk trick of creating a new kind of widget
by adding event handlers to a label widget in Visual Basic. But, I
didn't need try it and it worked okay for what I needed to do.
Of course, given how MS radically changed the language with
VB7.net and stopped supporting VB6, I don't think I'd ever use VB for
any code I thought might be valuable.
At least, that's what I'm playing on my cheapass used laptop. Both are amazing games that run on cheap hardware (and under cedega if you nice it.) Plus, high replayability for when you inadvertantly finish the game before running out of roadtrip.
Re:Ok, the race is on ...
on
Hacking Santa
·
· Score: 1
Er, seriously, if you look at the cost of the parts the guy used, it really would have been cheaper to use old PC guts instead of a Basic Stamp. The Santa looks big enough to hold a motherboard and hard drive in his bowl full of jelly, so of course you'd want to run Linux on it.
The only DRM'd audio format that the iPod plays is Apple's. So none of the other sellers of DRM'd music downloads can sell songs that play on the iPod while still maintaining maximum costumer contempt.
See? Lock-in.
I, for one, am outraged. Indeed, if I were any more outraged, I wouldn't be able to stop giggling.
I'd think that if you were going to hit someone up for funding, the people you'd want to go to are potential buyers such as large enterprises who are considering switching to or from Linux. Those are the folks who would most benefit from an objective study.
Firstly, software is vastly more complicated than house building.
So complicated that coordinating the workers becomes a serious
problem. That alone makes it a different problem.
Secondly, coding is design. It isn't construction.
That's the reason the classic methodologies never worked very
well. They were made on the assumption that development could be
split up into "architecture" and "construction", where the
"architects" developed flow charts and tables and the "builders" wrote
the actual code. But that's wrong.
In software, all of the people doing development--from the
architecture astronauts to the coders--all fall into the category of
"architects". The actual "building" is done by the compiler. And, of
course, they repeatedly "rebuild" the project and throw away the
result if it's not perfect.
That ability is what lets software get so complex when compared
to, say, construction, but it also means that the management issues
are much different.
A long time ago, I vowed that I wouldn't blog unless I did it on software I'd written myself. I did so mainly because I kept getting hoarse from yelling "It's just text and angle brackets" at every breathless article I read about content management systems and this was my own personal extended-middle-finger toward the whole web-hype industry.
And over all these years, I've kept my vow. I still don't blog.
buy music on CDs and rip/encode to mp3 under Linux (using lame and grip, if you must know). I store the CDs on a couple of vertical racks which take up about square foot of floor space. If that's too much, you can always get one of those big CD binders to hold the CD and artwork and pitch the jewel cases.
DRM hasn't really been a problem for me yet. I've found a grand total of one copy-protected CD that I considered worth buying and I managed to rip it on an older computer with a couple of days' effort. (Note to music industry: making me work harder to listen to music I've paid for than I'd have to just to pirate it is a bad idea). Your mileage may vary, of course. However, if you rip under Linux (or *BSD) using an old CD-ROM drive, you're pretty much in the clear. I'm not sure about how this works legally, though. In Canada, it's (currently) allowed and I think that an unmodified CD-ROM drive isn't going to count as a circumvention device (but IANAL).
Better still, of course, is to just not buy DRM'd CDs, but you can't have everything.
DRM-encumbered download services suck. Don't give them your money.
Interestingly enough, the Canadian site (which I use) doesn't do this. It's just the standard account/PIN login.
However, it does something much better. It's set up so that even if a phisher manages to get my account details and log in as me, he still can't get at my money. The best he (and I) can do is move money to and from my chequing account at another bank. That's not generally useful for phishers but it's all I need.
Which, by the way, is what Bruce Schnier basically advocates in TFA.
Wow. Whoever thought of this is very clever. And I don't
mean that in a sarcastic way.
Consider:
I have an idea for the killer web app. My plan is to write the
app and release it under the GPL and, if there's some interest in it,
make some money by selling hosting for it. There's money to be made
that way because it's easier to just buy the service from me than to
find hosting that'll let you run it yourself, but because it's GPL,
you always have that option if I go out of business or raise my
prices too much.
Basically, it's the LiveJournal business model.
So far, so good. I have an edge over my competitors because I
also maintain the app itself. Users know who I am but don't
necessarily know anything about the competitors.
But my competitors also have an advantage over me. They can take
my source code, spend maybe a tenth of the time and money I put into
it and make a better product than me. If I were writing a word
processor, this wouldn't be a problem--I'd just download their sources
and cherry-pick their work into the main distribution. That's what
Free Software is all about, after all. But with a web application,
it's different because they're not distributing the app. They
can screw me (and their customers) over by building a proprietary
service on top of my work.
The thing about the GPL, though, is that it doesn't in any way
restrict the use of the program. It only affects
modification and distribution (and this is the right thing, in
my opinion). If they require websites to make their source code
available, that would restrict use.
So, cleverly, they add the clause that if the original program has
a feature that lets you download the source code, you aren't allowed
to remove that feature.
Brilliant!
It closes the loophole without affecting use.
It lets the developer decide whether or not to make releasing
source code mandatory without modifying the license.
So if you want website operators to make the source code
available, you can. But if you want them to be free of that
requirement, you can do that too. It's the developer's decision and
this leaves it there. Frankly, I don't see what anybody's complaining about.
(Disclaimer: I'm not actually a Free Software advocate.)
"Not only does music file-swapping harm artists, but it also points to an erosion of respect for intellectual property that threatens Canada's economy and values at the core of
our society," said Graham Henderson, president of the Canadian Recording Industry Association, which commissioned the polls.
I'd laugh if I weren't crying. The idea that P2P leads to wrongdoing is so utterly laughable that you just need to wonder what brand of crack Mr. Henderson is smoking.
Also amusing (in a depressing sort of way):
Canadians illegally download 14 music CDs or other files from the Internet for every file they take from the web legally[.]
Recall that every Internet transaction basically consists of download a file. So between the Slashdot front page and the article submission form, I'd have had to download 21 CDs' worth of music just to keep up with the national average. No, wait, I forgot--there are embedded images! Aaaaah! I'm so behind!
Maybe modern browsers do it automatically? That might explain why my network connection is so slow.
(I suspect that what the study was actually talking about was file downloads over P2P services. That would actually make some sense, but it wouldn't be as impressive a headline.)
No it won't. This is one of those situations where market forces will do the right thing. DRM makes storage devices less useful. Most people who buy removable storage already know this. The ones that don't will find out as soon as they buy their DRM-encumbered device.
The basic principal of economics--sell people stuff they want--won't go away just because Hollywood has hyped up DRM. We--not the entertainment industry--are the customers. We pay their revenues and we'll stop doing that if they start making crappy (i.e. DRM'd) products. Given the sheer number of storage makers out there right now, it's not going to be difficult to switch to some else.
Yeah, I know what you mean. My own school made sure that bad
instructors didn't teach first- and second-year classes, and that
helped me a lot. However, I think it's a mistake to dismiss the value
of researchers as teachers.
One of the worst instructors I had was by all objective
measurements a really good teacher. He spoke perfect English in a
varied tone of voice, he structured his lectures well, he presented
the material in a clear, easily-understandable way, and yet it just
didn't work. Nobody in the class thought well of his teaching.
Eventually, I realized why--he wasn't interested in the
subject. He was just teaching.
On the other hand, I've had professors who aren't as good at the
job of teaching but they were much better at actually teaching the
material because of their enthusiasm. (I've also seen professors'
teaching get better as the term progressed, as the subject went from
basic stuff to the more interesting part of the subject.)
That's an advantage of having researchers teach. These are people
who are doing what they love and having them teach gives them the
opportunity to talk about it. That enthusiasm is much more important
to teaching than presentation style.
(Although yes, I have to agree--enthusiasm doesn't always make up
for inability to present the material in a coherent way.)
Slashdot Mirror
MINIX 3 is initially targeted at the following areas:
[...] $100 laptops for Third-World children
Also, MINIX is a microkernel-based OS, which is makes it way cooler than Linux or any of those other monolithic OSs.
(At which point, I come back to my computer and see Andrew S. Tanenbaum typing something.)
Yes, it's a crude experiment, based on usability[...]
No, it's not based on usability. If it were, you would be asking questions like, "Does it feel slow?" and "Can you do useful work with it." Your experiment is based on examining the contents of /proc/meminfo.
Actually, I have no idea what your experiment is supposed to prove, since you never say anything about how you interpreted the contents of /proc/meminfo. That pseudo-file gives you a lot of information about
the system's memory use and you never said which parts were
relevant and how.
What I am saying is that a modern Linux distribution has some very heavy system requirements, and they have jumped up an awful lot from previous distributions as little as six years ago.
I'm not disputing that. Although now that you bring it up, I'd like to point out that this is irrelevant. If you're going to build a $100 laptop, you're going to want to put together your own Linux distribution as well, so the real question is, "How small can you make this distribution and have it still be useful?" Since Redhat doesn't even try to keep Fedora small, its size isn't useful in this discussion.
Maybe if you looked at the sizes of floppy- and flash-based distributions, you'd have a point, but the sizes of mainstream distributions are irrelevant.
Get over it, get a life. There's more to the world than Linux - it's a tool, nothing more, and nothing less. If you can't take criticism of Linux, then maybe you should wear ear muffins :-)
Linux criticism I'm fine with. It's fuzzy thinking that grates on me. Also, I tried getting one of those "life" things but I find it interferes too much with my Slashdot posting.
cat /proc/meminfo
I may be wrong about this, but I'm pretty sure that's a bad way to measure memory usage. Modern Linux kernels just continue to keep stuff in memory until something else needs the RAM. The question is not how much RAM the kernel is using right now but how well it can juggle resources when they're limited. You can't figure that out without doing actual experiments on limited hardware.
Can you explain quine a little better for me?
A quine is simply a program which, when run, prints out its own source code. In my previous post, I sort of overloaded this a bit to mean a program that prints out its own executable. (Which, I suppose, would still be source code if you're insane enough to hand-assemble the thing with a hex editor.)
Actually, I went a bit further than that. My hypothetical virus is a program that can output two programs (a Windows binary and a Linux binary), each of which can also output both programs.
As for having a dual-platform binary, Linux has a mechanism to let you define arbitrary interpreters (or loaders?) for binary files. This would let you, for example, set up the kernel to run the Java VM on a JAR file whenever you set the execute flag on the JAR and run it as a program. Presumably, you could use this mechanism to run Windows binaries as well. You could put the Linux code in a dead section of the Windows executable, then set some harmless flag in the header. Windows would ignore the flag but you'd set up a special loader in Linux to check for it and if present, jump to the Linux part of the executable.
Offhand, I can think of three possibilities:
They've figured out how to hack together a fat binary.
It's possible that there's some sequence of bytes such that each operating system interprets it as the header for some kind of executable file and the Linux stuff is ignored by the Windows loader and vice versa. You'd end up with a Linux program, a Windows program and a special little bit of code that jumps to one or the other depending on what OS there is, all in one big executable.
(This would actually be pretty cool for non-malicious code as well. I'm not sure if it would be useful but it'd be cool.)
Maybe the virus spreads via buffer overflow. In this case, it can bypass the differences in loadfile format. Instead of loading from disk, it would load itself into a target program's RAM over the network via that buffer overflow, then take over.
For this to work, it would need to contain multiple exploits for various different bugs in various networked programs, but that's been done.
Of course, to do anything even remotely useful (in the virus sense of the word) after that, it would need to be able to use operating system resources. (The article seems to say that it doesn't use OS resources, but if that's the case, how can it spread? Disk and network access have to go through the OS.) The only way I can think of is for each system call routine to test for OS type and do the Linux thing or the Windows thing, depending.
You might be able to simplify that by dynamically calling the standard C library but even then, calling conventions and structure layouts are going to be different and that's going to make things really complicated.
Maybe the virus is a quine but capable of producing a Windows or Linux version of itself. That would be relatively easy to do--just tack on the Linux and Windows parts as data.
For that to work, though, the virus would need to know in advance what platform its target is running. That's tricky but not impossible.
Hmmm. Alternately, you could combine this with the previous method, putting together a polymorphic program that's just smart enough to identify the OS it's running under, then branch to either the Linux or Windows version of itself.
That sounds reasonable to me.
All that being said, I doubt that this is going to make it into the wild, if for no other reason than it's a huge amount of extra work to do just to get a five percent increase in penetration. And that doesn't even begin to take into account the differences in the various OSs' security.
The FA is a bit light on hard details, I noticed. This looks like a publicity stunt more than anything else.
Both Eric Sink (the founder of SourceGear) and Joel Spolsky seem to think so. (You'll have to search for the relevant articles yourself--I'm not going to dig through years worth of archives for you.)
Their thinking is:
On the other hand, the business guy is your friend and anyway, he's willing to talk to investors and answer the phone during the daytime (I'm assuming) so he's probably worth keeping around.
I think that what I'd do in your situation is give the business guy the job of CEO but retain a 51% ownership of the company. That lets him do the day-to-day business stuff and give the people he talks to a sense that they're talking to the guy in charge while at the same time letting you set him right if he tries to do something stupid.
Disclaimer: I have no actual experience in this. I'm just makin' stuff up.
So, yes, there are many good reasons to choose Eiffel over other OO languages.
Let me add another one. Eiffel has memory safety and garbage collection and also compiles your source code into standalone binary executables. I've had a lot of trouble finding a language that I can use for boring projects that combines those properties. Everything seems to either require a bunch of runtime files, has no user base or is C/C++. Eiffel appears to be a decent alternative.
Ah, yes, Microsoft Visual English++. Here are a couple of important MSVE++ words that you may have heard (with their definitions):
Innovation Cloning or buying an existing product, making incremental improvements to it and selling the result at price low enough to kill or marginalize the competition. Impossible We currently don't have a product that solves that problem.price :) (probably including support)
Just to add more fuel to the fire, I should point out that this isn't always the case. And since that bald assertion won't fly, I'll support it with a baseless anecdote:
A friend of mine who works at a large IT installation recently told me that he'd recommended using Oracle instead of Postgres because it was cheaper. Oracle's lower hardware requirements more than made up for the cost of the license in that particular situation.
Now, I believe it because I trust the people involved but I have no real motivation to do the research myself. I'm also pretty sure that you wouldn't find that unless you had the sort of requirements that make Database vendors salivate. Still, it shows that open-source isn't always the cheapest solution.
I've been fortunate enough to never have had to work in a seriously disfunctional workplace. However, from what I've read, the best way to combat this sort of management style (or at least to avoid getting shafted when they start handing out blame) is to make sure you have everything in writing and then make sure you have a complete set of copies.
Every time you have some objection to a decision, inform the manager of this in writing as a memo or email. If your company has some kind of system that automatically archives all project-related communication, that's ideal. But every time the manager asks you to do something that you consider a bad idea, you should make sure that there are records of
Remember to be polite and clear. Your intent should be to inform the manager of potential pitfalls with this decision, not to criticize. Any sort of rudeness will get you fingered as a malcontent and not a team player and it's vital that you come across as a perfect little cog in these records.
Finally, make sure you have your own copies of all of this communication and that you them it at home, out of reach of any possible after-hours doctoring.
Disclaimer: I've never yet had to do this, but I've read about it on USENET. Your mileage may vary.
Correct me if I'm wrong here, but what they're going to be doing is implementing a system where people who pay AOL a fee can bypass their spam filters, right?
So what this means is that:
Why don't they just start throwing bricks through their customers' windows? It'd be a much more efficient way of pissing them off.
There's also a Wikinews article about it here. It looks like most of the content of the BBC news article comes from it. BoingBoing also talks about it, pointing out that they did (gasp) investigative reporting. That article is here.
I have a bit of experience with both Tck/Tk and Visual Basic 5. Here's what I think:
Tcl/Tk is great for dashing off little graphical apps that do stuff. I once wrote a fully-functional GUI front end for "cdplayer" in 8 lines and ten minutes. It's the easiest tool I've ever used for hand-coding GUIs but you can also get GUI builders for it.
Good things:
Bad things:
If I were going to write a large or complex Windows app today, I'd probably write the interface in Tcl/Tk and the actual complex stuff in C.
As for Visual Basic, I didn't really use it enough to have an informed opinion. When I used it, I found that it was really easy to create a GUI but the IDE became irritating to use once I needed to write larger amounts of actual code. I also found the help reader annoying (but this was version 5--they may have improved since) and the documentation condescending.
It worked well as long as I didn't try anything too unusual. I don't think I could do Tcl/Tk trick of creating a new kind of widget by adding event handlers to a label widget in Visual Basic. But, I didn't need try it and it worked okay for what I needed to do.
Of course, given how MS radically changed the language with VB7.net and stopped supporting VB6, I don't think I'd ever use VB for any code I thought might be valuable.
At least, that's what I'm playing on my cheapass used laptop. Both are amazing games that run on cheap hardware (and under cedega if you nice it.) Plus, high replayability for when you inadvertantly finish the game before running out of roadtrip.
Er, seriously, if you look at the cost of the parts the guy used, it really would have been cheaper to use old PC guts instead of a Basic Stamp. The Santa looks big enough to hold a motherboard and hard drive in his bowl full of jelly, so of course you'd want to run Linux on it.
What fucking lock-in scheme?
The only DRM'd audio format that the iPod plays is Apple's. So none of the other sellers of DRM'd music downloads can sell songs that play on the iPod while still maintaining maximum costumer contempt.
See? Lock-in.
I, for one, am outraged. Indeed, if I were any more outraged, I wouldn't be able to stop giggling.
I'd think that if you were going to hit someone up for funding, the people you'd want to go to are potential buyers such as large enterprises who are considering switching to or from Linux. Those are the folks who would most benefit from an objective study.
Two things:
Firstly, software is vastly more complicated than house building. So complicated that coordinating the workers becomes a serious problem. That alone makes it a different problem.
Secondly, coding is design. It isn't construction.
That's the reason the classic methodologies never worked very well. They were made on the assumption that development could be split up into "architecture" and "construction", where the "architects" developed flow charts and tables and the "builders" wrote the actual code. But that's wrong.
In software, all of the people doing development--from the architecture astronauts to the coders--all fall into the category of "architects". The actual "building" is done by the compiler. And, of course, they repeatedly "rebuild" the project and throw away the result if it's not perfect.
That ability is what lets software get so complex when compared to, say, construction, but it also means that the management issues are much different.
It worked for me.
A long time ago, I vowed that I wouldn't blog unless I did it on software I'd written myself. I did so mainly because I kept getting hoarse from yelling "It's just text and angle brackets" at every breathless article I read about content management systems and this was my own personal extended-middle-finger toward the whole web-hype industry.
And over all these years, I've kept my vow. I still don't blog.
buy music on CDs and rip/encode to mp3 under Linux (using lame and grip, if you must know). I store the CDs on a couple of vertical racks which take up about square foot of floor space. If that's too much, you can always get one of those big CD binders to hold the CD and artwork and pitch the jewel cases.
DRM hasn't really been a problem for me yet. I've found a grand total of one copy-protected CD that I considered worth buying and I managed to rip it on an older computer with a couple of days' effort. (Note to music industry: making me work harder to listen to music I've paid for than I'd have to just to pirate it is a bad idea). Your mileage may vary, of course. However, if you rip under Linux (or *BSD) using an old CD-ROM drive, you're pretty much in the clear. I'm not sure about how this works legally, though. In Canada, it's (currently) allowed and I think that an unmodified CD-ROM drive isn't going to count as a circumvention device (but IANAL).
Better still, of course, is to just not buy DRM'd CDs, but you can't have everything.
DRM-encumbered download services suck. Don't give them your money.
Interestingly enough, the Canadian site (which I use) doesn't do this. It's just the standard account/PIN login.
However, it does something much better. It's set up so that even if a phisher manages to get my account details and log in as me, he still can't get at my money. The best he (and I) can do is move money to and from my chequing account at another bank. That's not generally useful for phishers but it's all I need.
Which, by the way, is what Bruce Schnier basically advocates in TFA.
Wow. Whoever thought of this is very clever. And I don't mean that in a sarcastic way.
Consider:
I have an idea for the killer web app. My plan is to write the app and release it under the GPL and, if there's some interest in it, make some money by selling hosting for it. There's money to be made that way because it's easier to just buy the service from me than to find hosting that'll let you run it yourself, but because it's GPL, you always have that option if I go out of business or raise my prices too much.
Basically, it's the LiveJournal business model.
So far, so good. I have an edge over my competitors because I also maintain the app itself. Users know who I am but don't necessarily know anything about the competitors.
But my competitors also have an advantage over me. They can take my source code, spend maybe a tenth of the time and money I put into it and make a better product than me. If I were writing a word processor, this wouldn't be a problem--I'd just download their sources and cherry-pick their work into the main distribution. That's what Free Software is all about, after all. But with a web application, it's different because they're not distributing the app. They can screw me (and their customers) over by building a proprietary service on top of my work.
The thing about the GPL, though, is that it doesn't in any way restrict the use of the program. It only affects modification and distribution (and this is the right thing, in my opinion). If they require websites to make their source code available, that would restrict use.
So, cleverly, they add the clause that if the original program has a feature that lets you download the source code, you aren't allowed to remove that feature.
Brilliant!
So if you want website operators to make the source code available, you can. But if you want them to be free of that requirement, you can do that too. It's the developer's decision and this leaves it there. Frankly, I don't see what anybody's complaining about.
(Disclaimer: I'm not actually a Free Software advocate.)
"Not only does music file-swapping harm artists, but it also points to an erosion of respect for intellectual property that threatens Canada's economy and values at the core of our society," said Graham Henderson, president of the Canadian Recording Industry Association, which commissioned the polls.
I'd laugh if I weren't crying. The idea that P2P leads to wrongdoing is so utterly laughable that you just need to wonder what brand of crack Mr. Henderson is smoking.
Also amusing (in a depressing sort of way):
Canadians illegally download 14 music CDs or other files from the Internet for every file they take from the web legally[.]
Recall that every Internet transaction basically consists of download a file. So between the Slashdot front page and the article submission form, I'd have had to download 21 CDs' worth of music just to keep up with the national average. No, wait, I forgot--there are embedded images! Aaaaah! I'm so behind!
Maybe modern browsers do it automatically? That might explain why my network connection is so slow.
(I suspect that what the study was actually talking about was file downloads over P2P services. That would actually make some sense, but it wouldn't be as impressive a headline.)
It will only be a matter of time, really.
No it won't. This is one of those situations where market forces will do the right thing. DRM makes storage devices less useful. Most people who buy removable storage already know this. The ones that don't will find out as soon as they buy their DRM-encumbered device.
The basic principal of economics--sell people stuff they want--won't go away just because Hollywood has hyped up DRM. We--not the entertainment industry--are the customers. We pay their revenues and we'll stop doing that if they start making crappy (i.e. DRM'd) products. Given the sheer number of storage makers out there right now, it's not going to be difficult to switch to some else.
Yeah, I know what you mean. My own school made sure that bad instructors didn't teach first- and second-year classes, and that helped me a lot. However, I think it's a mistake to dismiss the value of researchers as teachers.
One of the worst instructors I had was by all objective measurements a really good teacher. He spoke perfect English in a varied tone of voice, he structured his lectures well, he presented the material in a clear, easily-understandable way, and yet it just didn't work. Nobody in the class thought well of his teaching. Eventually, I realized why--he wasn't interested in the subject. He was just teaching.
On the other hand, I've had professors who aren't as good at the job of teaching but they were much better at actually teaching the material because of their enthusiasm. (I've also seen professors' teaching get better as the term progressed, as the subject went from basic stuff to the more interesting part of the subject.)
That's an advantage of having researchers teach. These are people who are doing what they love and having them teach gives them the opportunity to talk about it. That enthusiasm is much more important to teaching than presentation style.
(Although yes, I have to agree--enthusiasm doesn't always make up for inability to present the material in a coherent way.)