But thinking something like Apt would be a silver bullet for home users is strictly a fantasy. First it would have to be run by MSFT to incorporate the Windows patches as well as third party updates, which would lead to vendors screaming and probably an antitrust investigation and I'm sure the EU would find a reason to have a shitfit, but then MSFT would get to deal with 3 or 4 years worth of lawsuits when they refuse to "provide" the myriad of programs that insist on installing toolbars or unrelated programs, like Java (toolbar) or iTunes (unrelated Safari and Quicktime).
So while having a central repository works for Linux, it simply would never work for Windows. Between trialware, crapware, toolbar installers, and unrelated installers you would either make it a one stop shop for crap which means the users would never allow it to run, or MSFT would spend the next decade in court for refusing to allow crapware into the repository. So sorry, it just wouldn't work.
How about a standard place in Windows where a newly installed program could register itself?
Like, "I am FooBar version 69, and updates to me will be available at http://foobar.org/blah
and signed with this public key". Then you could have a machine-global Update Everything button
go through them and do updates as needed.
Doesn't solve dependency trackning though.
(Not that I care -- it's the Windows users' problems, not mine.)
Loose leaf binder.
Text file.
Or, if I could be bothered, Excel worksheet.
A text file can be placed under revision control using e.g. CVS so it
can be safely used by many people and from many places. (You also get
an audit trail for free).
Excel doesn't work well with that. Plus, you need Windows machines to read it.
So I'd vote for text file (although I'd prefer Excel to
a web application/relational database monster).
The DRAC sucks for remote console. I've been impressed by the HP iLO2 (although not by their expensive licensing) because the consoles and virtual media work on any platform that can run Java. Of course, they also have a special "integrated console" to make IE users feel special, but I didn't find it offered any value that was missing on the Java versions. I've tried the iLO2 on Linux, Mac, and Windows without any issues. That's the way Java is supposed to be. Even the DRAC4 that didn't use activex would throw some stupid error like "you're not using java on windows".
But all that also sucks compared to accessing iLO via ssh, and then accessing the
(serial) console via iLO(*). I hate web interfaces and Java applets, and it feels
stupid to watch a text interface, rendered as a bitmap and transfered as such
over a network.
(*) For my use cases that is: using the console and hitting the power/reset buttons
when I manage to crash the Linux kernel.
Way, way off-topic -- I know. But for this company to use the name "Prometheus" because of its association with knowledge/wisdom (Prometheus brought fire to humans, which is why Zeus punished him), but then contradict the modern association with defiance of authority... well, I find it humorous, anyway.
It's more ironic than that.
The Prometheus legend (as I recall it) isn't about how wise he was or how he defied authority.
It's about him going "information wants to be free!",
giving away the gods' secrets to the humans, and being shafted for it.
Kind of like that norwegian DeCSS guy.
... the web and "service oriented architectures" are where a lot of programming is going to take place in the future. You won't have programs running on individual computer systems so much anymore, but rather networked programs talking to other networked programs to get stuff done.
Also, in the future we will commute to work in Jetsons-style flying cars.
I realize it is "in" right now, but it serves no sensible purpose for most programs,
(except to lock the user to his service provider).
Of course full-disk encryption, as lots of people have already suggested, but since you want the thief's time to be wasted, remember to password-protect the BIOS and disallow booting from USB drives or external units. Same goes for GRUB if you were on Linux. That way the thief will not be able to resell the netbook.
Yes, the thief could remove the BIOS battery, but he would have to tear the case open. If he knew how to open a laptop without breaking it, he has more skill than I would associate with a petty thief.
I don't know what it's like where you live, but around here a thief is likely to be
a junky who wants to transform your laptop into smack ASAP.
The fence he sells it to has more skill; maybe he even specializes in computers.
If the course is about Java, why do you expect them to do pair programming?
(I assume you mean Pair Programming, not just cooperating to solve the tasks.
If you mean the latter, it's just a matter of revision control using SVN or whatever,
which they should do anyway.)
Anyway, one free tool that comes to mind is screen(1) (aka Gnu Screen) in multiuser mode.
That makes two or more users share a bunch of Unix terminals in real time.
In short, this is how C standard evolution works: One compiler adds a feature. People use that feature. People complain that other compilers don't have it. Other compilers implement it. The C standards committee approves (a tidied up version of) the extension.
But here one important thing to point out is that the GCC people (for C and C++ at least)
seem less fond of adding GCC-specific language extensions to their compilers these days,
and lets you easily avoid them. You no longer get the feeling they're saying:
"here is a new operator you might want to use -- it will never be standardized, but you will
never again use some other compiler anyway, will you?"
So he argued against specialization and comparative advantage, the pillars that make an economy work in the first place? No wonder his ideas failed so badly.
Well, that's why you look at it first. If you can't tell the difference, and want the "best quality" anyway, you got the same disease an as "audiophile", and I recommend some Monster display cables to go with it.:P
The OP obviously wants batch processing of perhaps thousands of images.
Even if he's not, it's not the same thing.
You may want to enlarge parts of the image, change its contrast and so on later.
It's hard to tell what artifacts hide at that level by just looking at the whole
unmodified image.
p
For being a bunch of Linux nerds, you all have a poor grasp of C/C++. That coder made a few mistakes. First, he used an implicit cast of a pointer to an int/bool. [---]
You mean if(!p)... ?
That's the normal style for many of us, and surely common in the Linux kernel.
It's also perfectly safe.
As a Dane living in the UK, having a surname ending with sen, I'm proper fed up with having to spell my surname to everyone taking my name down. To me Larsen sounds Danish and Larson sounds Swedish. Sorry for rambling.
The normal Swedish spelling is Larsson.
Larsen is a danish or norwegian guy.
Larson is a scandinavian immigrant to the US, or a swede who wants to insinuate
he has more money than some random Larsson.
Larzon is a swede who's in the sleazier part of the entertainment industry.
They live in tribes and use stone-age technology. That makes them stoneage tribesmen, no matter the cause. It doesn't matter why they live in such conditions, but if nobody would recognise them as such, nobody would help them improve their technological savvy.
Stone-age?
I'm guessing they have at least the same stuff my grandfather had before he
bought the Massey-Ferguson and got rid of the horse in 1956.
That's approximately 3,000 years after the stone age ended around here...
Mapping them to foot pedals, though, would be kind of hot. I'd start writing articles in VI if I had a rig like that, just for the sheer coolness.
I don't recall the foot pedals on sewing machines being cool
I disagree. I remember them from back at school, and now and then I stop and think:
"We've had foot pedals on bloody sewing machines since forever.
Why can't I buy an USB pedal for my computer, when me--machine I/O is so often the bottleneck?"
But possibly your foot is not sensitive enough for the many quick taps you tend to do on a keyboard or mouse.
Their terminals have keyboard shortcuts for cutting and pasting. You can sort of do that in 'screen' by hitting a set of key combinations so tedious it's quicker to reach for the mouse, or you could do what mac users get, which is hold down a meta key and move the cursor about.
oi, konsole authors.. are you listening?
Try xterm for a real terminal emulator. I am not impressed by the Gnome and KDE terminal emulators.
At least the Gnome one shows up regularly as the worst memory hog on our big multiuser systems.
I don't think you need specific application support, though.
It should be possible to bind Button1--3 X11 events to those useless "Internet" keys present on
so many keyboards.
I've never gotten around to trying it, though. Or even googled for it.
You have to know tech either way, whether you continue to be in tech or go in to management
I want to work where you do. My company hires management based on management experience, not experience in the field I work in. Then they quit after two months because they don't know what's going on and all the working stiffs are making fun of them. Hire new manager, rinse, and repeat.
Non-techie managers can be really good.
As long as they have talent for the job (which is really helping me do *my* job properly).
And ex-techie managers can be really bad, when they think they are still fit to
make technical decisions based on (a) what was cutting edge back in 1995 or (b) random
buzzword technology from some glossy magazine.
Yes. TCP was/is designed to detect and correct data transmission errors. The information coding is highly redundant, and the error correction and detection is implemented in each of several layers. (See, http://www.faqs.org/rfcs/rfc793.html ). The probability of an undetected error is very small. The datalink layer in most networks typically provide an undetected error rate in the neighborhood of 2^-32. Then the upper layer tcp does another layer of error coding, providing a combined error rate of something like 2^-64. That is fine for most practical purposes.
Wrong! The TCP checksum is 16 bits, and you cannot know what links your data travels on across the Internet.
See Stevens' "TCP Illustrated vol 1" -- he references one guy who saw quite a lot of bad TCP checksums on a
live network. Around 1/2^16 of those pass undetected to the application.
Also, TCP does not do error correction, nor is it implemented in "several layers".
And "highly redundant"... I don't have the slightest idea what you're talking about here.
Have you even *read* the RFC?
I'm sorry, but I've worked in this area for years. I was responsible for moving data and source files to and from Unix to DOS to VMS to OSs that are even deader than VMS, and the problem is hardly unique to "notepad".
He's clearly talking about problems *in Windows*, and he doesn't need to care or know about
VMS, EBCDIC IBM systems or whatever to have an opinion about that.
Still, he's wrong.
A problem isn't fixed because N applications have kludged around it.
I'm not going to apply such kludges to every trivial Perl script I write -- I expect text files
on Windows to be DOS files, and if they are not, it's the user's problem, not mine.
(My favorite strategy is to ignore Windows, though.)
On the other hand, if you really want a "guaranteed delivery" with formal acknowledgment and validation, try using a secured protocol like SSH or SFTP or a messaging system like JMS with a handshaking architecture around it. There are plenty of Open Source architectures you can build around (xBus for example), but I don't know of any ready-built executables. Commercially, vendors like IBM (MQ) and Tibco have products that deal with the messaging at a similar level.
I can't help reading that and thinking "why on earth would anyone want to go build an IBM MQSeries messaging, uh, architecture when (as you point out) you can just use something like SFTP or rsync-over-ssh which everyone uses,
works, and is free as the air I breathe?"
Wrong. FTP has a binary mode. This is probably the reason his files are missing several k at the destination.
Using FTP ASCII mode for binary files would be increadibly stupid, but yeah, it sounds like that could be it.
Sending a binary file in ascii mode is the ONLY TIME I've ever had a file not transfer entirely/correctly using FTP. Unless of course there is a network error/timeout, etc, but the FTP client always errored out in those cases.
Calling ftp from a.BAT script or whatever it's called in DOS and *not* checking its exit code
is another likely candidate.
Otherwise, I don't believe FTP has any checksums, so I'd expect bit errors here and there --
things the TCP and link layer checksums did not catch in 1/65536 of the cases.
Using SFTP over an already secure network will only slow things down greatly.
Depends entirely on the CPU speed of the endpoints relative to the link speed.
If you enable compression and the files aren't already compressed, it can be a lot faster.
UDP is actually a great basis for accelerated file transfer. Several file transfer utilities / protocols have been built around it.
I find that hard to believe (the "great basis" part -- I am sure lots of people have tried and thought
they succeeded).
Which of the guarantees that TCP gives you are you prepared to give up for file transfer?
(Note that you're not allowed to give up performance for other users in the network.)
I've recently
considered adding some sophistication by implementing a version
control system like subversion, git, or bazaar, but have found some
shortcomings in automating commits and pushing updates to all systems.
Like Homer Simpson once said: "If something seems hard, it's probably not worth doing".
Forget about the automagical sync idea, and version control suddenly becomes attractive.
I keep the important parts of my $HOME in CVS, with the repository available over ssh.
I commit my changes when I have something ready, and I update when I suspect there is something to update.
You *cannot* automate this -- a human needs to be around to resolve conflicts, in the rare cases
where there are any.
One interesting aspect of this is that it simplifies backups.
A directory under version control doesn't need backups -- you backup the repository instead.
You don't have to spend time excluding certain files/file name patterns from the backup to save space;
you have implicitly excluded them by not commiting them.
And it'll work for 99.9% of people.
I really don't get the desire for people to make shit more complicated and less reliable than it needs to be.
Very rarely would anyone need anything other than a simple sync job, manual or automated.
Really?
Don't people ever want to edit foo.txt on computer A, without worrying
that they'll destroy work they might have done on computers B, C and D the week before?
Figuring out what an rsync-based approach would do to that file -- *that's* complicated and unreliable!
I use rsync for backups, and for moving files in general. I like it.
But for the important things I use CVS. My dotfiles are in CVS, and so are texts and source code.
(Not digital photos though -- I keep a master directory of those on one computer, and back it up semi-regularly.)
Complicated? Not really.
Slashdot Mirror
How about a standard place in Windows where a newly installed program could register itself? Like, "I am FooBar version 69, and updates to me will be available at http://foobar.org/blah and signed with this public key". Then you could have a machine-global Update Everything button go through them and do updates as needed. Doesn't solve dependency trackning though.
(Not that I care -- it's the Windows users' problems, not mine.)
A text file can be placed under revision control using e.g. CVS so it can be safely used by many people and from many places. (You also get an audit trail for free).
Excel doesn't work well with that. Plus, you need Windows machines to read it. So I'd vote for text file (although I'd prefer Excel to a web application/relational database monster).
I don't know. Maybe he's a Unix guy and knows those three well. Maybe the rest of his coworkers do, too. Etc.
But all that also sucks compared to accessing iLO via ssh, and then accessing the (serial) console via iLO(*). I hate web interfaces and Java applets, and it feels stupid to watch a text interface, rendered as a bitmap and transfered as such over a network.
(*) For my use cases that is: using the console and hitting the power/reset buttons when I manage to crash the Linux kernel.
It's more ironic than that.
The Prometheus legend (as I recall it) isn't about how wise he was or how he defied authority. It's about him going "information wants to be free!", giving away the gods' secrets to the humans, and being shafted for it. Kind of like that norwegian DeCSS guy.
Also, in the future we will commute to work in Jetsons-style flying cars. I realize it is "in" right now, but it serves no sensible purpose for most programs, (except to lock the user to his service provider).
I don't know what it's like where you live, but around here a thief is likely to be a junky who wants to transform your laptop into smack ASAP. The fence he sells it to has more skill; maybe he even specializes in computers.
If the course is about Java, why do you expect them to do pair programming? (I assume you mean Pair Programming, not just cooperating to solve the tasks. If you mean the latter, it's just a matter of revision control using SVN or whatever, which they should do anyway.)
Anyway, one free tool that comes to mind is screen(1) (aka Gnu Screen) in multiuser mode. That makes two or more users share a bunch of Unix terminals in real time.
But here one important thing to point out is that the GCC people (for C and C++ at least) seem less fond of adding GCC-specific language extensions to their compilers these days, and lets you easily avoid them. You no longer get the feeling they're saying: "here is a new operator you might want to use -- it will never be standardized, but you will never again use some other compiler anyway, will you?"
But he did use the word "cleavage" ...
The OP obviously wants batch processing of perhaps thousands of images.
Even if he's not, it's not the same thing. You may want to enlarge parts of the image, change its contrast and so on later. It's hard to tell what artifacts hide at that level by just looking at the whole unmodified image. p
You mean if(!p) ... ?
That's the normal style for many of us, and surely common in the Linux kernel.
It's also perfectly safe.
The normal Swedish spelling is Larsson.
Larsen is a danish or norwegian guy. Larson is a scandinavian immigrant to the US, or a swede who wants to insinuate he has more money than some random Larsson. Larzon is a swede who's in the sleazier part of the entertainment industry.
Stone-age? I'm guessing they have at least the same stuff my grandfather had before he bought the Massey-Ferguson and got rid of the horse in 1956. That's approximately 3,000 years after the stone age ended around here ...
I disagree. I remember them from back at school, and now and then I stop and think: "We've had foot pedals on bloody sewing machines since forever. Why can't I buy an USB pedal for my computer, when me--machine I/O is so often the bottleneck?"
But possibly your foot is not sensitive enough for the many quick taps you tend to do on a keyboard or mouse.
Try xterm for a real terminal emulator. I am not impressed by the Gnome and KDE terminal emulators. At least the Gnome one shows up regularly as the worst memory hog on our big multiuser systems.
I don't think you need specific application support, though. It should be possible to bind Button1--3 X11 events to those useless "Internet" keys present on so many keyboards. I've never gotten around to trying it, though. Or even googled for it.
Non-techie managers can be really good. As long as they have talent for the job (which is really helping me do *my* job properly). And ex-techie managers can be really bad, when they think they are still fit to make technical decisions based on (a) what was cutting edge back in 1995 or (b) random buzzword technology from some glossy magazine.
Wrong! The TCP checksum is 16 bits, and you cannot know what links your data travels on across the Internet. See Stevens' "TCP Illustrated vol 1" -- he references one guy who saw quite a lot of bad TCP checksums on a live network. Around 1/2^16 of those pass undetected to the application.
Also, TCP does not do error correction, nor is it implemented in "several layers". And "highly redundant" ... I don't have the slightest idea what you're talking about here.
Have you even *read* the RFC?
He's clearly talking about problems *in Windows*, and he doesn't need to care or know about VMS, EBCDIC IBM systems or whatever to have an opinion about that.
Still, he's wrong. A problem isn't fixed because N applications have kludged around it. I'm not going to apply such kludges to every trivial Perl script I write -- I expect text files on Windows to be DOS files, and if they are not, it's the user's problem, not mine. (My favorite strategy is to ignore Windows, though.)
I can't help reading that and thinking "why on earth would anyone want to go build an IBM MQSeries messaging, uh, architecture when (as you point out) you can just use something like SFTP or rsync-over-ssh which everyone uses, works, and is free as the air I breathe?"
Using FTP ASCII mode for binary files would be increadibly stupid, but yeah, it sounds like that could be it.
Calling ftp from a .BAT script or whatever it's called in DOS and *not* checking its exit code
is another likely candidate.
Otherwise, I don't believe FTP has any checksums, so I'd expect bit errors here and there --
things the TCP and link layer checksums did not catch in 1/65536 of the cases.
Depends entirely on the CPU speed of the endpoints relative to the link speed. If you enable compression and the files aren't already compressed, it can be a lot faster.
I find that hard to believe (the "great basis" part -- I am sure lots of people have tried and thought they succeeded). Which of the guarantees that TCP gives you are you prepared to give up for file transfer? (Note that you're not allowed to give up performance for other users in the network.)
Yeah, a splash screen.
Like Homer Simpson once said: "If something seems hard, it's probably not worth doing". Forget about the automagical sync idea, and version control suddenly becomes attractive.
I keep the important parts of my $HOME in CVS, with the repository available over ssh. I commit my changes when I have something ready, and I update when I suspect there is something to update. You *cannot* automate this -- a human needs to be around to resolve conflicts, in the rare cases where there are any.
One interesting aspect of this is that it simplifies backups. A directory under version control doesn't need backups -- you backup the repository instead. You don't have to spend time excluding certain files/file name patterns from the backup to save space; you have implicitly excluded them by not commiting them.
Really? Don't people ever want to edit foo.txt on computer A, without worrying that they'll destroy work they might have done on computers B, C and D the week before? Figuring out what an rsync-based approach would do to that file -- *that's* complicated and unreliable!
I use rsync for backups, and for moving files in general. I like it. But for the important things I use CVS. My dotfiles are in CVS, and so are texts and source code. (Not digital photos though -- I keep a master directory of those on one computer, and back it up semi-regularly.) Complicated? Not really.