We don't like rebooting until we know why we're rebooting.
Sure, rebooting clears stuck mounts, clears any processes hung in kernel space, resets all kernel mutexes, and so on.
But we want to know WHY IT BROKE in the first place. Rebooting just clears the symptoms, and now we don't have the state data to fix it. So, when we know what the fault is, a reboot becomes acceptable.
But "oh just reboot it, maybe it will start working?" No.
You do know some vendors replace the native Windows Firewall with a crappier one?
I spent an hour doing LAN traces trying to get someone's new Windows 7 box to talk to a WebDAV fileserver. No matter what I did, not a pip from the Windows machine on the relevant sockets; the only thing that went through was the DNS lookup. But all the interface plumbing seemed fine.
I ultimately found a vendor-specific firewall that was blocking nearly all outbound communication.
I removed it and turned on the Windows Firewall (which has actually heard of file servers) and suddenly it was working. And everything else got a lot faster.
For scanners, I make sure the scanner works with something like VueScan or SANE. For printers, let there be PostScript.
After dealing with one of the early, inexpensive home-use USB scanners (Microtek X6 USB or something like that).... It had drivers that worked with Mac OS 8.1. Not 8.0, not 8.5, not 8.6. Just exactly 8.1. Fortunately, SANE could run it, so scanning moved to Linux.
I ultimately got a rather better scanner that works very well with VueScan, and gave the old one to a friend with a fairly old Windows rig. (Their Windows drivers weren't quite as bad; but that doesn't do anything for me.)
Between that and those stupid FusionIO SSD PCIe cards, I refuse to deal with hardware that needs a proprietary driver from the hardware vendor. Comply with a standard, handle generic functions with the generic driver. Then you can expose extra function with the vendor extension mechanism.
Not only would the pump not accept "I don't have a ZIP code", the monkey in the box couldn't handle a cash transaction. (!!!!!)
Fortunately, I like to fill up when I get to 1/4 tank, so was able to find a gas station that actually knew how to take money in exchange for gasoline.
The only problem is, they'd have to agree to the GPL.
I won't recommend a Linksys router for anyone who wants something "fancier" than a WRT54GL. It's so hard to tell what you're going to wind up with, and some of them are flakier than a good pie crust. Some have heat issues. Many will trash parts of their config on power blips--doing things like exposing your entire LAN as the Wi Fi network "linksys" with no security at all.
I won't recommend _ANY_ SOHO router that has to run the manufacturer's firmware. Unless you've got enough $$$ for the Apple Airport Extreme Base Station one.
Or an admin that has carefully secured a Solaris 10 machine, starting with shutting down telnet and the r* daemons, fingerd and all the other cruft. But then he installs a patch cluster......and suddenly all that crap is running again.
Network devices aren't reliably named ethX already. If you assume that, you've got issues. We've got machines with strange network interfaces, and they come up with different names.
So, if you're going to try to figure out what interfaces to play with, you should ask the system what the network interfaces are. Don't try and glob/dev/.
So, ifconfig -a tells me I've got eth0, sit0, lo, vmnet1 and vmnet8 on my RHEL workstation. sit0 is down, the rest are all operating and valid. On an RHEL server, we've got bond0, eth0, eth1, and lo--and you absolutely SHOULD NOT attempt to play with eth0 or eth1 directly on that host.
Congrats, you just re-invented the Apple App Store. (And/or SElinux; though I haven't seen SElinux configured that aggressively.)
That's basically what it does: your.app bundle (NeXTStep-speak for specially-suffixed directory) is self-contained and isn't allowed to fiddle with Other Stuff. It's preferences and user data folders are constrained to follow a specific path name convention.
It's like./configure --prefix=/where/I/want/it but with enforcement from the installer.
When I had to do some documents on the local setup for a couple of change control programs, I did all my Windows 2000 screenshots by VNCing to the Windows machine and using 'xv' on Linux. Not only did that result in reasonable file formats (rather than BMP), but I could happily crop the result before saving.
Windows users probably have a Better Way, but I'm not a Windows user.
Drobo is an excellent example of the time vs. money trade-off. If you've got the time, you don't need to spend the money.
Since my set-up is currently 11 RAID1 pairs, I've been eyeballing the Supermicro SC846E1 chassis; but the price tag on that had me spending the $120 to import a couple of port multiplier eSATA bridge boards from the UK... and I'm really happy with the performance on that. (It's not going to win any awards, but it is more than plenty for my needs.)
As for the article topic:
Backups, to multiple storage volumes. My picture album is (now) on the household Linux server, and backed up to 3 different external disks in rotation. Plus, I keep separate copies on the laptop: so I download a card onto the laptop, then later download the card to the Linux server. (RAIDed volumes do not count towards the number of backups.)
It is best, if at all possible, to keep the phone wire bit as short as possible to the DSL modem. Using a POTS splitter, you want to pull off the line for DSL before any other branching in the circuitry; have all the branches after the DSL filter. (Look up impedance matching and signal reflections and all that fun stuff for why.)
So, there is merit to a really short phone cord and an up-to-maximum-spec Ethernet run. Ethernet is robust and reliable compared to the DSL modulation: partly because the Ethernet guys knew they were going to be carrying high-frequency signals where line and junction impedance matters, and the phone guys knew they were carrying voice-quality current-loop baseband analog audio--and no-one else was allowed to run phone service, so they could do whatever they wanted.
But there's a right way and a wrong way to achieve that. This is an excellent example of "really really wrong".
It's worse than that. All the method invocations are done in binary, so if things "move about" in the underlying C structure, you're hosed. It's not just mangling, it's actual data structure layout.
You'd be hosed in C if you moved structure members around, too; but your functions weren't part of the structure. In C++, they are--or rather, can be. It depends on their virtual-ness... and the inheritance... and probably other things. If you're really, really, really good, you can update class definitions and retain binary runtime compatibility. I've only seen people take that sort of care with compiler runtime libraries--anywhere else, and the time becomes approximately infinite while the benefit of "not having two versions installed" remains constant.
The solution is to do method invocation with some sort of symbolic runtime search; SmallTalk, Objective C, Perl, Python, and Java all do this in one way or another. But that's why C++ was so appealing when it was young: it was faster than those other languages (at least, those that existed at the time).
I always wondered about cycle time comparisons with the 6502. If memory serves, it used a split-phase clock; which effectively creates a clock multiplier without having to deal with high frequencies. That is, 01 and 02 were the same frequency as 00, just offset by 'X' degrees in the cycle.
So, where the 6800 had multiple input clocks per operation, the 6502 could make use of multiple clock edges within a single master clock cycle... a bit like some of the double-pumped and double-edged clocks we've got on SDRAM today.
Which is still great, as we all know power consumption goes up with the square of the clock speed (for any given circuit; hence the need for narrower features at high frequencies). So by cleverly spreading the "parts" of an opcode across the several clock phases, you got enough time for the gates to go valid... but without having a 4 MHz master oscillator.
Or memory doesn't serve, 'cause I left the VIC-II disabled too long and so DRAM refresh didn't happen and it's all gone now....
I run systems where you have to log in and enter decryption keys after a reboot. So a power failure at the data centre means I need to SSH in, enter the LUKS keys, and bring up the services that access user data. Same thing if I need a data centre admin to do something to the server: they can reboot to single-user without being able to log on, but they can't get at any of the LUKS volumes. (Once the system is in multiuser, they can't log on.)
My home system only brings up enough disks and filesystems to boot to multiuser at first. THEN it starts the SSH server. Once SSH is up, it finally starts bringing up the other 30TB of disks--so I can even do most forms of filesystem, logical volume and RAID recovery over SSH.
Bank of Montreal doesn't display the verification picture until you've entered a "secret answer" sort of thing, like the "What was your first pet?" kind of question. It will set a cookie on your browser, if you like, so you don't have to keep doing that part. THEN you get to enter your account number and password.
So the interceptor would have to remember to pass the cookie on... so let's hope they're intercepting by DNS spoofing, not just using a phishing site at a different hostname.
I could see it being the end of the world for Kagi....
Ahhh, the numerous Kagi e-mail receipts for Mac shareware I've got archived. Dating back to System 7.5.3 on a Performa 6300CDAV. It's amazing I still use Macs after that one.
You can easily build a GUI on a good script-able CLI. You can even build Web interfaces to them... though the "good"ness of that idea depends on the security around your web server.
You can rarely build a CLI on a GUI, no matter how good. You would have had to build all the CLI hooks into the GUI code anyway, at which point you might as well have done it the other way up in the first place.
It makes much more sense to start with a strong CLI and build the GUI on top; most UNIX admin GUIs are exactly that. Heck, everyone who uses the Wrong Editor (vi) is using a TUI built on top of a line editor (ex).
The other thing, of course, is admins deal with broken stuff. The more stuff you need, the harder it will be to deal with when things are broken.
Which is a perfect example of a terrible error message. And there's plenty of bad examples like that to crib from, too. (In your particular example, sure, you'll have the "at line XXX" so someone can start digging around in the code... but that's something only suitable for quick-and-dirty hack scripts.)
What you need to know is WHAT, WHERE and HOW. You know WHO (the program), and are trying to figure out WHY. I've often had to resort to strace -etrace=file to find out "What file couldn't be opened? Why couldn't it be opened?"
So, sticking with perl:
open FILE,"filename.txt" or die "Cannot open \"filename.txt\" for reading--$!\n";
Your example will give only the errno, which is what I'm calling HOW [it went wrong]. WHAT went wrong is the "open for reading". WHERE it went wrong is "filename.txt".
I generally wrap such calls with a library; that way, I don't have the error handling littering up every call-site. But if you're using an exception-oriented language, we need the SAME INFORMATION once it turns into an error message!
Oh yeah: For error recovery code, files can't be opened for more reasons than just, "It's not there." You can try all you want, but if (say) the filesystem has gone read-only due to a disk controller failure resulting in journal abort, you might want to do something different. That one's strictly hypothetical, haven't had it happen in over a week--ever since I replaced that faulty cable....
And, frankly, buying stuff on-line is just going back to my parents' younger days. Only now, you've got much, much, much more choice.
Back in their youth, you had a few "high street" shops. But if you didn't want to drive down town to the big department store, you ordered from their catalogue. You'd fill out a form and send it in, or call and place your order. In cities, they'd have their own delivery fleet; for rural areas, they'd use parcel post. They even had their own charge cards (not credit: pay it all at the end of the month) so you could get your order without having to wait to mail in a cheque.
So. Moving on a bit, we now have competition at several levels in that stack. With better parcel service from the Post Office, and competing couriers that pretend to be able to handle residential deliveries, just about anyone can ship you something. There are charge, credit and debit cards that can be used on-line, stores don't need their own credit department. (If you want to pretend, there are companies like HSBC or MBNA that will "back" your store-brand credit card.) You don't need to send out paper catalogues: people will actually use their own equipment to view electronic catalogues... which is really just your web site.
So I can price-match between an Ontario-based retailer, a British Columbia-based retailer, and a US-based retailer to get the computer bits I want. (All three actually have at least warehouses in Ontario, so shipping is similar. Only one of them has a retail presence in Ontario.)
Which sure beats choosing between Simpson-Sears and Eaton's.
Re:That's one heck of a "long goodbye"
on
Goodbye, VGA
·
· Score: 1
DVI actually supports both analog and digital. The analog version is called DVI-A, and is signal-compatible with VGA; you just need a passive cable adapter. This can be at either end: so you can have a VGA plug on a PC and a DVI-A compatible plug on a monitor or vice-versa.
But usually you get monitors that have digital-only DVI ports, these are called DVI-D. A DVI-A cable can't plug in to them.
The version that has both analog and digital is called DVI-I; both DVI-A and DVI-D cables can connect. These are very common on video cards, and you can use the passive DVI-A to VGA cable adapter to get the analog signals from it to a VGA monitor.
So, I have a DVI-I-capable KVM switch. Which would be great: I could connect both VGA and DVI machines to it. Except, my monitor is DVI-D, so the monitor will never see the VGA signals on the DVI-A lines; it has a physically separate VGA port for DVI-A or VGA.... (I think with the right splitters and adapters I could do it... but a cheap DVI-capable card for my fileserver was more practical. Especially since the old one got Capacitor Plague.)
Slashdot Mirror
And, will it run on the open hardware Mechaduino platform?
We don't like rebooting until we know why we're rebooting.
Sure, rebooting clears stuck mounts, clears any processes hung in kernel space, resets all kernel mutexes, and so on.
But we want to know WHY IT BROKE in the first place. Rebooting just clears the symptoms, and now we don't have the state data to fix it. So, when we know what the fault is, a reboot becomes acceptable.
But "oh just reboot it, maybe it will start working?" No.
You do know some vendors replace the native Windows Firewall with a crappier one?
I spent an hour doing LAN traces trying to get someone's new Windows 7 box to talk to a WebDAV fileserver. No matter what I did, not a pip from the Windows machine on the relevant sockets; the only thing that went through was the DNS lookup. But all the interface plumbing seemed fine.
I ultimately found a vendor-specific firewall that was blocking nearly all outbound communication.
I removed it and turned on the Windows Firewall (which has actually heard of file servers) and suddenly it was working. And everything else got a lot faster.
For scanners, I make sure the scanner works with something like VueScan or SANE. For printers, let there be PostScript.
After dealing with one of the early, inexpensive home-use USB scanners (Microtek X6 USB or something like that).... It had drivers that worked with Mac OS 8.1. Not 8.0, not 8.5, not 8.6. Just exactly 8.1. Fortunately, SANE could run it, so scanning moved to Linux.
I ultimately got a rather better scanner that works very well with VueScan, and gave the old one to a friend with a fairly old Windows rig. (Their Windows drivers weren't quite as bad; but that doesn't do anything for me.)
Between that and those stupid FusionIO SSD PCIe cards, I refuse to deal with hardware that needs a proprietary driver from the hardware vendor. Comply with a standard, handle generic functions with the generic driver. Then you can expose extra function with the vendor extension mechanism.
It's to prevent Canadians from buying gas.
Not only would the pump not accept "I don't have a ZIP code", the monkey in the box couldn't handle a cash transaction. (!!!!!)
Fortunately, I like to fill up when I get to 1/4 tank, so was able to find a gas station that actually knew how to take money in exchange for gasoline.
The only problem is, they'd have to agree to the GPL.
I won't recommend a Linksys router for anyone who wants something "fancier" than a WRT54GL. It's so hard to tell what you're going to wind up with, and some of them are flakier than a good pie crust. Some have heat issues. Many will trash parts of their config on power blips--doing things like exposing your entire LAN as the Wi Fi network "linksys" with no security at all.
I won't recommend _ANY_ SOHO router that has to run the manufacturer's firmware. Unless you've got enough $$$ for the Apple Airport Extreme Base Station one.
You skip the PSN agreement. You do not skip the firmware license.
The PSN thing is important because it is PSN that Sony is using to justify the California court.
Yeah, that RLL stuff will never catch on. ST-506 FTW, the ST-412 is never gonna make it!
Or an admin that has carefully secured a Solaris 10 machine, starting with shutting down telnet and the r* daemons, fingerd and all the other cruft. But then he installs a patch cluster... ...and suddenly all that crap is running again.
Don't ask me how I know that.
Network devices aren't reliably named ethX already. If you assume that, you've got issues. We've got machines with strange network interfaces, and they come up with different names.
So, if you're going to try to figure out what interfaces to play with, you should ask the system what the network interfaces are. Don't try and glob /dev/.
So, ifconfig -a tells me I've got eth0, sit0, lo, vmnet1 and vmnet8 on my RHEL workstation. sit0 is down, the rest are all operating and valid. On an RHEL server, we've got bond0, eth0, eth1, and lo--and you absolutely SHOULD NOT attempt to play with eth0 or eth1 directly on that host.
Congrats, you just re-invented the Apple App Store. (And/or SElinux; though I haven't seen SElinux configured that aggressively.)
That's basically what it does: your .app bundle (NeXTStep-speak for specially-suffixed directory) is self-contained and isn't allowed to fiddle with Other Stuff. It's preferences and user data folders are constrained to follow a specific path name convention.
It's like ./configure --prefix=/where/I/want/it but with enforcement from the installer.
Ahh, that takes me back.
When I had to do some documents on the local setup for a couple of change control programs, I did all my Windows 2000 screenshots by VNCing to the Windows machine and using 'xv' on Linux. Not only did that result in reasonable file formats (rather than BMP), but I could happily crop the result before saving.
Windows users probably have a Better Way, but I'm not a Windows user.
Drobo is an excellent example of the time vs. money trade-off. If you've got the time, you don't need to spend the money.
Since my set-up is currently 11 RAID1 pairs, I've been eyeballing the Supermicro SC846E1 chassis; but the price tag on that had me spending the $120 to import a couple of port multiplier eSATA bridge boards from the UK... and I'm really happy with the performance on that. (It's not going to win any awards, but it is more than plenty for my needs.)
As for the article topic:
Backups, to multiple storage volumes. My picture album is (now) on the household Linux server, and backed up to 3 different external disks in rotation. Plus, I keep separate copies on the laptop: so I download a card onto the laptop, then later download the card to the Linux server. (RAIDed volumes do not count towards the number of backups.)
It is best, if at all possible, to keep the phone wire bit as short as possible to the DSL modem. Using a POTS splitter, you want to pull off the line for DSL before any other branching in the circuitry; have all the branches after the DSL filter. (Look up impedance matching and signal reflections and all that fun stuff for why.)
So, there is merit to a really short phone cord and an up-to-maximum-spec Ethernet run. Ethernet is robust and reliable compared to the DSL modulation: partly because the Ethernet guys knew they were going to be carrying high-frequency signals where line and junction impedance matters, and the phone guys knew they were carrying voice-quality current-loop baseband analog audio--and no-one else was allowed to run phone service, so they could do whatever they wanted.
But there's a right way and a wrong way to achieve that. This is an excellent example of "really really wrong".
As an electrical engineer, with very fond memories of hacking with the MC68HC11 MCU, I'd suggest you're missing a degree in marketing.
'Scuse me, I've got this uncontrollable urge to get some Freeduino hobby boards....
It's worse than that. All the method invocations are done in binary, so if things "move about" in the underlying C structure, you're hosed. It's not just mangling, it's actual data structure layout.
You'd be hosed in C if you moved structure members around, too; but your functions weren't part of the structure. In C++, they are--or rather, can be. It depends on their virtual-ness... and the inheritance... and probably other things. If you're really, really, really good, you can update class definitions and retain binary runtime compatibility. I've only seen people take that sort of care with compiler runtime libraries--anywhere else, and the time becomes approximately infinite while the benefit of "not having two versions installed" remains constant.
The solution is to do method invocation with some sort of symbolic runtime search; SmallTalk, Objective C, Perl, Python, and Java all do this in one way or another. But that's why C++ was so appealing when it was young: it was faster than those other languages (at least, those that existed at the time).
I always wondered about cycle time comparisons with the 6502. If memory serves, it used a split-phase clock; which effectively creates a clock multiplier without having to deal with high frequencies. That is, 01 and 02 were the same frequency as 00, just offset by 'X' degrees in the cycle.
So, where the 6800 had multiple input clocks per operation, the 6502 could make use of multiple clock edges within a single master clock cycle... a bit like some of the double-pumped and double-edged clocks we've got on SDRAM today.
Which is still great, as we all know power consumption goes up with the square of the clock speed (for any given circuit; hence the need for narrower features at high frequencies). So by cleverly spreading the "parts" of an opcode across the several clock phases, you got enough time for the gates to go valid... but without having a 4 MHz master oscillator.
Or memory doesn't serve, 'cause I left the VIC-II disabled too long and so DRAM refresh didn't happen and it's all gone now....
I run systems where you have to log in and enter decryption keys after a reboot. So a power failure at the data centre means I need to SSH in, enter the LUKS keys, and bring up the services that access user data. Same thing if I need a data centre admin to do something to the server: they can reboot to single-user without being able to log on, but they can't get at any of the LUKS volumes. (Once the system is in multiuser, they can't log on.)
My home system only brings up enough disks and filesystems to boot to multiuser at first. THEN it starts the SSH server. Once SSH is up, it finally starts bringing up the other 30TB of disks--so I can even do most forms of filesystem, logical volume and RAID recovery over SSH.
Bank of Montreal doesn't display the verification picture until you've entered a "secret answer" sort of thing, like the "What was your first pet?" kind of question. It will set a cookie on your browser, if you like, so you don't have to keep doing that part. THEN you get to enter your account number and password.
So the interceptor would have to remember to pass the cookie on... so let's hope they're intercepting by DNS spoofing, not just using a phishing site at a different hostname.
I could see it being the end of the world for Kagi....
Ahhh, the numerous Kagi e-mail receipts for Mac shareware I've got archived. Dating back to System 7.5.3 on a Performa 6300CDAV. It's amazing I still use Macs after that one.
You can easily build a GUI on a good script-able CLI. You can even build Web interfaces to them... though the "good"ness of that idea depends on the security around your web server.
You can rarely build a CLI on a GUI, no matter how good. You would have had to build all the CLI hooks into the GUI code anyway, at which point you might as well have done it the other way up in the first place.
It makes much more sense to start with a strong CLI and build the GUI on top; most UNIX admin GUIs are exactly that. Heck, everyone who uses the Wrong Editor (vi) is using a TUI built on top of a line editor (ex).
The other thing, of course, is admins deal with broken stuff. The more stuff you need, the harder it will be to deal with when things are broken.
Which is a perfect example of a terrible error message. And there's plenty of bad examples like that to crib from, too. (In your particular example, sure, you'll have the "at line XXX" so someone can start digging around in the code... but that's something only suitable for quick-and-dirty hack scripts.)
What you need to know is WHAT, WHERE and HOW. You know WHO (the program), and are trying to figure out WHY. I've often had to resort to strace -etrace=file to find out "What file couldn't be opened? Why couldn't it be opened?"
So, sticking with perl:
open FILE,"filename.txt" or die "Cannot open \"filename.txt\" for reading--$!\n";
Your example will give only the errno, which is what I'm calling HOW [it went wrong]. WHAT went wrong is the "open for reading". WHERE it went wrong is "filename.txt".
I generally wrap such calls with a library; that way, I don't have the error handling littering up every call-site. But if you're using an exception-oriented language, we need the SAME INFORMATION once it turns into an error message!
Oh yeah: For error recovery code, files can't be opened for more reasons than just, "It's not there." You can try all you want, but if (say) the filesystem has gone read-only due to a disk controller failure resulting in journal abort, you might want to do something different. That one's strictly hypothetical, haven't had it happen in over a week--ever since I replaced that faulty cable....
And, frankly, buying stuff on-line is just going back to my parents' younger days. Only now, you've got much, much, much more choice.
Back in their youth, you had a few "high street" shops. But if you didn't want to drive down town to the big department store, you ordered from their catalogue. You'd fill out a form and send it in, or call and place your order. In cities, they'd have their own delivery fleet; for rural areas, they'd use parcel post. They even had their own charge cards (not credit: pay it all at the end of the month) so you could get your order without having to wait to mail in a cheque.
So. Moving on a bit, we now have competition at several levels in that stack. With better parcel service from the Post Office, and competing couriers that pretend to be able to handle residential deliveries, just about anyone can ship you something. There are charge, credit and debit cards that can be used on-line, stores don't need their own credit department. (If you want to pretend, there are companies like HSBC or MBNA that will "back" your store-brand credit card.) You don't need to send out paper catalogues: people will actually use their own equipment to view electronic catalogues... which is really just your web site.
So I can price-match between an Ontario-based retailer, a British Columbia-based retailer, and a US-based retailer to get the computer bits I want. (All three actually have at least warehouses in Ontario, so shipping is similar. Only one of them has a retail presence in Ontario.)
Which sure beats choosing between Simpson-Sears and Eaton's.
DVI actually supports both analog and digital. The analog version is called DVI-A, and is signal-compatible with VGA; you just need a passive cable adapter. This can be at either end: so you can have a VGA plug on a PC and a DVI-A compatible plug on a monitor or vice-versa.
But usually you get monitors that have digital-only DVI ports, these are called DVI-D. A DVI-A cable can't plug in to them.
The version that has both analog and digital is called DVI-I; both DVI-A and DVI-D cables can connect. These are very common on video cards, and you can use the passive DVI-A to VGA cable adapter to get the analog signals from it to a VGA monitor.
So, I have a DVI-I-capable KVM switch. Which would be great: I could connect both VGA and DVI machines to it. Except, my monitor is DVI-D, so the monitor will never see the VGA signals on the DVI-A lines; it has a physically separate VGA port for DVI-A or VGA.... (I think with the right splitters and adapters I could do it... but a cheap DVI-capable card for my fileserver was more practical. Especially since the old one got Capacitor Plague.)
Your AT&T example will fail on systems with interruptible system calls: it has no mechanism for distinguishing EINTR from any other failure mode.
On Plan 9, that may be a valid assumption. Under SuS, SVR4, and POSIX, it's not.