I recently reinstalled Oneric/ia64 on a few machines because of the recently included gcc-arm packages which always were a pain to self-compile.
I added a http-proxy (squid) on my local fileserver/NAS and used the netinstall through that proxy: No duplicate downloads, up to date packages for everything and I could start installing without waiting for the.ISO to finish downloading.
I highly recommend that method, and it should work for most distributions out there, possibly even for WindowsUpdate;-)
Cables don't get "old" by themselves, but they might have been installed incorrectly from the start (too tight bending, swapped pairs/cables, twisted pairs separated for a longer distance, shields not connected properly, grounding done wrong). Furthermore mechanical stress (too much work being done on a patch panel over the course of several years, cables pulled hard while moving racks,...) might have damaged parts of the cabling.
To cut a long story short: Properly done CAT5 should be good enough for Gigabit, but often what's called CAT5 works well for 100 Mbit networks even though it doesn't meet the specs.
Get a decent LAN tester (not just two computers, using "ping") that prints out attenuation, crosstalk and all the other things... and preferably tells you what "category" your cabling still is compatible with. Replace all the stuff that's out of spec. Then you have hard numbers you can rely on should you ever ponder if your local network infrastructure can handle 100M/1G/10G bit/s. Everything else is guesswork.
It is easier for the app developer to work around the problem by not requiring root privlege.
And if you really need elevated privileges, there's a proven mechanism (suid) that's been working for quite a while. Of course, you can have security holes that way, but at least the fundamental problems (like messing around with the elevated process) have been solved for ages...
But the recording accuracy doesn't just fall off a few dbs at between 16 and 20 KHz. It goes to square wave. That is fine for me, because as long as I cannot hear sounds at 48kHz or higher, a square- and a sine-wave of 16 kHz are identical! (see e.g. here: http://cnx.org/content/m0041/latest/)
Ok, stop it.... I'm impressed already. Now it seems that you and your company are lucky to have both users demanding a very powerful product and obviously are willing to pay for it and your developers are very knowledgeable. And I'll go with Joel (www.joelonsoftware.com) who once stated, that if you have great programmers as a matter of fact, most 3rd-party libraries in comparison are indeed of very low quality.
But -depending on the number of developers you have at hand- it might not even be feasible to code everything yourself, so the big question to answer is: Which of my components will I code myself and which will I put together by using 3rd-party code.
And for most applications out there -especially if you look at in-house development- the answer is probably, that they should have used a lot more 3rd-party code, because their own programming is so shitty;-)....
Your faith in the timestamp counter is disturbing. People don't generally program in assembly and they don't measure time using a counter or run programs on very old systems. On every machine I have tried this on, doing millions of sys_getpid calls (non-cached) measuring in real wallclock time on Athlon, Pentium 4, single core, dual core, etc it generally comes out to ~1200 cycles... to read a single int from the kernel.
Here you go (you can email me if you want the program source, but it's now reduced to a for()-loop, 10 million times, and inside that loop there is a getpid()):
rage ~ $ time./cycles
real 0m11.858s user 0m6.140s sys 0m5.720s
11.858 / 1e7 * 133e6 is 157 cycles.
Maybe on your system there is some overhead, a SMP kernel needing locking or whatever strange thing, but on that pentium, I get this many cycles. And not 1500.
Windows NT can do the equivalent of getpid much faster, because the top of the process's address space has a number of kernel data structures mapped into it (read only).
To be honest, I don't care a bit how fast my operating system determines a process' pid, but rather took the getpid()-function as the prototype for the simplest possible syscall to test the minimal latency of calling any kernel function. That's also why I did not use getpid() library function directly, that function has the nasty habit of calling the kernel only once and caching the result from that moment on...
And still, 190 cycles is still much less than what you guessed linux would need (1500 cycles).
By the way, the TSC is not necessarily a cycle counter.
The intel architecture manual describes the TSC counters as ticking with the usual processor clock (the usual bus clock times multiplier) or with the maximum processor clock on core CPUs (where I think the multiplier might change or be different for different cores, I'm not sure on the last one). Nevertheless, on the machine I counted cycles for getpid() it's ticking nicely with the expected 133 MHz frequency, I just checked by counting the cycles a sleep(1) needs.
(Inte 64 and IA32 Architectures Software Developer's Manual, November 2006, Vol 3B, Page 18-37. I still can't believe that there are programmers on Intel hardware which are NOT regularly checking into this book;-)...)
sys_getpid takes maybe 5 instructions in a 'message passing' safe os, but takes 1500 cycles in linux.
Sorry, but you are wrong. On a Pentium i586, 133 MHz (my "home router") in a loop of 4096 calls of getpid() I need 192 cycles for 4086 out of 4096 loop iterations.
rdtsc ### Read Timestamp Counter mov %eax,%ebx ## store timestamp ctr mov $0x14,%eax ## syscall 0x14 is getpid int $0x80 ## execute syscall mov %eax,0xffffffe4(%ebp) ## save result rdtsc ### Read Timestamp Counter
If you only time "rdtsc, mov, rdtsc" it needs 13 cycles. I'd hardly call 179 cycles a big overhead, especially if you consider that the Pentium4 is supposed to have a faster "SYSENTER" instruction which the small pentium lacks. And I'll be very impressed if you show me any operating system that can do a getpid in 5 instructions if the information about the pid needs (let's say) dereferencing of 2 pointers....
Meaningless, I use mics from cheap Chinese dynamics to rare vintage U47's. It's about time that notebooks and PDAs come with XLR connectors and phantom power for our serious VoIP-needs. Maybe they can make a special tube version that supplies filament and bias voltages, too?;-)
ZFS seems to want to take all over the disk subsystem. Why? Is there a reason why it needs its own snapshot capabilities, instead of just using LVM? Because this kind of snapshots are just much more primitive than the ones in ZFS. Basically you can branch of a complete subdirectory instantly, and branch of one from that one, too... It's the best way to do backups (not against disk failure, but against accidental overwrite/deletion) ever invented. Show me how to do that with the LVM snapshot kludge.
Wow, finally, a new block size, never heard of that idea before.
Doesn't anyone remember that SCSI-drives that support a changeable block-size are around since basically forever? Of course with harddisks it was used mostly to account for additional error-correcting / parity bits, but also magneto-optical media could be written with 512 or 2k (if I remember correctly).
> and a retractable DC cord with multiple connectors on it
And exactly how long will it take till someone sues whoever installed the outlets because he fried his expensive gizmo by using the wrong voltage, polarity, connector,...? Sounds like a very stupid idea to install those outlets in the houses of typical dumbheads.
frankly, I think that's not a good way to write code.
Exceptions are great to *REDUCE* the clutter created by the endless if(doit){ error() }; sequences in non-exception-savy programming languages, but you just seem to use exceptions as some different type of return code for your functions.
You assume that some specific exception is thrown by your functions, because you don't distinguish between the possible causes in your catch{} blocks.
I'd say, a better way of writing would have been:
try {
all_your();
functions();
from_above(); } catch {
# catch different exceptions here }
and in that catch{} block (don't know how perl does it...) you can distinguish between different types of exceptions, using you own subclasses of exceptions for your application specific errors. Note that even in the "generic" class of exceptions script languages allow you to obtain backtraces within the exception handler so even in some very obscure case you could spew out a error message like:
2005-05-12 07:24:02 obscure/function.pl(open_devnull):123 open("/dev/null"): no such file or directory, called by function.pl(prepare_env):876, main.pl(initialize):1954, main.pl(TOPLEVEL): 9154
while for the "somewhat expected" errors you could write out:
2005-05-12 07:24:02 Could not open/dev/null: permission denied, please check if your chroot environment is set up correctly.
fredegar vogel $ cc -Wall -g slashdot.c slashdot.c:1: warning: return type defaults to `int' slashdot.c: In function `main': slashdot.c:2: error: `a' undeclared (first use in this function) slashdot.c:2: error: (Each undeclared identifier is reported only once slashdot.c:2: error: for each function it appears in.)
locks outgoing port 25 to prevent spam, thereby prohibiting the use of any mail server other than mail.isp.com
That's why you should use the port "submission" (587/tcp) for email-submission. Of course, the mailserver sould not just treat that port identical as smtp (25/tcp) but only allow email-submissions from authenticated clients, preferably encrypted,...
If you consider doing more complex stuff with AVR microcontrollers, the "Ethernut 2" functions as a very interesting development environment (or even as a complete building block for products/projects). For about EUR 150 you get:
ATMega128 Microcontroller + 512 kByte RAM Serial ports: RS232 + RS485 100 MBit Ethernet most digital I/O and analog inputs of the Mega128 accessible on a row of jumpers.
The complete operating system (providing TCP/IP networking for example) that's running on that board is availably as sourcecode, you use your trusted gcc/binutils toolchain.
Programming is done via straight cables from your parallel port to the ethernut (or you can buy ready built programmers very cheap).
...and the old PCIIa GPIB-interface cards for the PC (they have a 8bit ISA bus!) are supported by linux-gpib since not long ago!
http://linux-gpib.sourceforge.net/
They are no longer supported by national instruments since windows 3.11/DOS, so you can get them very cheap (or for free) and they work very well under linux!
Ok, this does not answer the initial question, but:
Better than any method of data recovery is to have a look at your system log or the S.M.A.R.T. values of your drive as long as it's alive and to look out for signs of impending doom.
That way you can backup your important data (music, divx-videos,...?) before everything fails!
It's quite strange when you hear someone complaining that his important data is lost, and "oh, yes, it made those funny noises for half a year!"
1.) nmap your network. Find https-servers (port 443), imaps, pop3s, ssmtp. Those should run ssl on connect. 1.b) find imap, pop3, smtp servers that support STARTTLS 1.c) use openssl s_client -showcerts -connect host:port to get the certificate 2.) ? 3.) Profit!
Do you know that you *can* configure kermit to have all the features of z-modem? Bigger windows, not escaping anything non-printable, etc... You just had to configure it (if you used the *real* kernit)... Kermit really made a great tool, including executing shell commands on the remote node etc... More like "ftp" or "ssh" than the pure z-modem transfers. But of course, the kermit versions included in most terminal programs sucked a lot...
Slashdot Mirror
I recently reinstalled Oneric/ia64 on a few machines because of the recently included gcc-arm packages which always were a pain to self-compile.
I added a http-proxy (squid) on my local fileserver/NAS and used the netinstall through that proxy: No duplicate downloads, up to date packages for everything and I could start installing without waiting for the .ISO to finish downloading.
I highly recommend that method, and it should work for most distributions out there, possibly even for WindowsUpdate ;-)
Cables don't get "old" by themselves, but they might have been installed incorrectly from the start (too tight bending, swapped pairs/cables, twisted pairs separated for a longer distance, shields not connected properly, grounding done wrong). Furthermore mechanical stress (too much work being done on a patch panel over the course of several years, cables pulled hard while moving racks, ...) might have damaged parts of the cabling.
To cut a long story short: Properly done CAT5 should be good enough for Gigabit, but often what's called CAT5 works well for 100 Mbit networks even though it doesn't meet the specs.
Get a decent LAN tester (not just two computers, using "ping") that prints out attenuation, crosstalk and all the other things... and preferably tells you what "category" your cabling still is compatible with. Replace all the stuff that's out of spec. Then you have hard numbers you can rely on should you ever ponder if your local network infrastructure can handle 100M/1G/10G bit/s. Everything else is guesswork.
It is easier for the app developer to work around the problem by not requiring root privlege.
And if you really need elevated privileges, there's a proven mechanism (suid) that's been working for quite a while. Of course, you can have security holes that way, but at least the fundamental problems (like messing around with the elevated process) have been solved for ages...
With a laptop aufgebohrten [bohren is to drill] card for 23 euros
aufgebohrt means pimped. So they used a laptop and a improved version of the DECT card.
Ok, stop it.... I'm impressed already. Now it seems that you and your company are lucky to have both users demanding a very powerful product and obviously are willing to pay for it and your developers are very knowledgeable. And I'll go with Joel (www.joelonsoftware.com) who once stated, that if you have great programmers as a matter of fact, most 3rd-party libraries in comparison are indeed of very low quality.
;-)....
But -depending on the number of developers you have at hand- it might not even be feasible to code everything yourself, so the big question to answer is: Which of my components will I code myself and which will I put together by using 3rd-party code.
And for most applications out there -especially if you look at in-house development- the answer is probably, that they should have used a lot more 3rd-party code, because their own programming is so shitty
Here you go (you can email me if you want the program source, but it's now reduced to a for()-loop, 10 million times, and inside that loop there is a getpid()):
rage ~ $ time
real 0m11.858s
user 0m6.140s
sys 0m5.720s
11.858 / 1e7 * 133e6 is 157 cycles.
Maybe on your system there is some overhead, a SMP kernel needing locking or whatever strange thing, but on that pentium, I get this many cycles. And not 1500.
To be honest, I don't care a bit how fast my operating system determines a process' pid, but rather took the getpid()-function as the prototype for the simplest possible syscall to test the minimal latency of calling any kernel function. That's also why I did not use getpid() library function directly, that function has the nasty habit of calling the kernel only once and caching the result from that moment on...
And still, 190 cycles is still much less than what you guessed linux would need (1500 cycles).
The intel architecture manual describes the TSC counters as ticking with the usual processor clock (the usual bus clock times multiplier) or with the maximum processor clock on core CPUs (where I think the multiplier might change or be different for different cores, I'm not sure on the last one). Nevertheless, on the machine I counted cycles for getpid() it's ticking nicely with the expected 133 MHz frequency, I just checked by counting the cycles a sleep(1) needs.
(Inte 64 and IA32 Architectures Software Developer's Manual, November 2006, Vol 3B, Page 18-37. I still can't believe that there are programmers on Intel hardware which are NOT regularly checking into this book
Sorry, but you are wrong. On a Pentium i586, 133 MHz (my "home router") in a loop of 4096 calls of getpid() I need 192 cycles for 4086 out of 4096 loop iterations.
rdtsc ### Read Timestamp Counter
mov %eax,%ebx ## store timestamp ctr
mov $0x14,%eax ## syscall 0x14 is getpid
int $0x80 ## execute syscall
mov %eax,0xffffffe4(%ebp) ## save result
rdtsc ### Read Timestamp Counter
If you only time "rdtsc, mov, rdtsc" it needs 13 cycles. I'd hardly call 179 cycles a big overhead, especially if you consider that the Pentium4 is supposed to have a faster "SYSENTER" instruction which the small pentium lacks. And I'll be very impressed if you show me any operating system that can do a getpid in 5 instructions if the information about the pid needs (let's say) dereferencing of 2 pointers....
for our serious VoIP-needs. Maybe they can make a special tube version that supplies
filament and bias voltages, too?
Wow, finally, a new block size, never heard of that idea before.
0 0/ul10k300.htm allows 512, 516, 520, 524, 528 but there are devices that do several steps between 128 and 2k or so...)
Doesn't anyone remember that SCSI-drives that support a changeable block-size are around since basically forever? Of course with harddisks it was used mostly to account for additional error-correcting / parity bits, but also magneto-optical media could be written with 512 or 2k (if I remember correctly).
(first hit I found: http://www.starline.de/en/produkte/hitachi/ul10k3
> and a retractable DC cord with multiple connectors on it
...? Sounds like a very stupid idea to install those outlets in the houses of typical dumbheads.
And exactly how long will it take till someone sues whoever installed the outlets because he fried his expensive gizmo by using the wrong voltage, polarity, connector,
Greetings from 230V-AC-land.
http://insti.physics.sunysb.edu/~siegel/parodies/s tuperspace.pdf
frankly, I think that's not a good way to write code.
/dev/null: permission denied, please check if your chroot environment is set up correctly.
Exceptions are great to *REDUCE* the clutter created by the endless if(doit){ error() }; sequences in non-exception-savy programming languages, but you just seem to use exceptions as some different type of return code for your functions.
You assume that some specific exception is thrown by your functions, because you don't distinguish between the possible causes in your catch{} blocks.
I'd say, a better way of writing would have been:
try {
all_your();
functions();
from_above();
} catch {
# catch different exceptions here
}
and in that catch{} block (don't know how perl does it...) you can distinguish between different types of exceptions, using you own subclasses of exceptions for your application specific errors. Note that even in the "generic" class of exceptions script languages allow you to obtain backtraces within the exception handler so even in some very obscure case you could spew out a error message like:
2005-05-12 07:24:02 obscure/function.pl(open_devnull):123 open("/dev/null"): no such file or directory, called by function.pl(prepare_env):876, main.pl(initialize):1954, main.pl(TOPLEVEL): 9154
while for the "somewhat expected" errors you could write out:
2005-05-12 07:24:02 Could not open
fredegar vogel $ cc -Wall -g slashdot.c
slashdot.c:1: warning: return type defaults to `int'
slashdot.c: In function `main':
slashdot.c:2: error: `a' undeclared (first use in this function)
slashdot.c:2: error: (Each undeclared identifier is reported only once
slashdot.c:2: error: for each function it appears in.)
Maybe this document is enlightening? http://www.microsoft.com/windows2000/techinfo/resk it/en-us/default.asp?url=/windows2000/techinfo/res kit/en-us/regentry/33563.asp
locks outgoing port 25 to prevent spam, thereby prohibiting the use of any mail server other than mail.isp.com
...
That's why you should use the port "submission" (587/tcp) for email-submission. Of course, the mailserver sould not just treat that port identical as smtp (25/tcp) but only allow email-submissions from authenticated clients, preferably encrypted,
If you consider doing more complex stuff with AVR microcontrollers, the "Ethernut 2" functions as a very interesting development environment (or even as a complete building block for products/projects). For about EUR 150 you get:
ATMega128 Microcontroller + 512 kByte RAM
Serial ports: RS232 + RS485
100 MBit Ethernet
most digital I/O and analog inputs of the Mega128 accessible on a row of jumpers.
The complete operating system (providing TCP/IP networking for example) that's running on that board is availably as sourcecode, you use your trusted gcc/binutils toolchain.
Programming is done via straight cables from your parallel port to the ethernut (or you can buy ready built programmers very cheap).
...and the old PCIIa GPIB-interface cards for the PC (they have a 8bit ISA bus!) are supported by linux-gpib since not long ago!
http://linux-gpib.sourceforge.net/
They are no longer supported by national instruments since windows 3.11/DOS, so you can get them very cheap (or for free) and they work very well under linux!
Ok, this does not answer the initial question, but:
...?) before everything fails!
Better than any method of data recovery is to have a look at your system log or the S.M.A.R.T. values of your drive as long as it's alive and to look out for signs of impending doom.
That way you can backup your important data (music, divx-videos,
It's quite strange when you hear someone complaining that his important data is lost, and "oh, yes, it made those funny noises for half a year!"
Hi,
1.) nmap your network. Find https-servers (port 443), imaps, pop3s, ssmtp. Those should run ssl on connect.
1.b) find imap, pop3, smtp servers that support STARTTLS
1.c) use openssl s_client -showcerts -connect host:port to get the certificate
2.) ?
3.) Profit!
Chris
"75% of Network Connections Not From Browsers"
Does this count as a network-connection from a browser? Sure makes a lot of traffic, but on a 100MBit Network it's quite useable.
sh$ DISPLAY=remote:0 mozilla
Do you know that you *can* configure kermit to have all the features of z-modem? Bigger windows, not escaping anything non-printable, etc... You just had to configure it (if you used the *real* kernit)... Kermit really made a great tool, including executing shell commands on the remote node etc... More like "ftp" or "ssh" than the pure z-modem transfers. But of course, the kermit versions included in most terminal programs sucked a lot...
There is a ATA command that formats the whole drive (needs some time), then you have a passwordless but very empty drive which you can use again.