Then the solenoid went on my Honda Accord, and I found out you can't buy a solenoid any more. You have to buy the whole "alternator assembly" which includes alternator, solenoid, voltage regulator, and God knows what else -- to the tune of $400. I came THIS CLOSE to ripping the goddamn "alternator assembly" apart and fixing the solenoid myself, except I actually have to work for a living. So frustrating.
Solenoid? Alternator? The solenoid is part of the starter assembly, bozo. It engages the starter cogwheel with the flywheel and closes the circuit that allows current to flow through the starter motor.
Gee, you almost managed to pass off as someone who knows what he's talking about, but you blew it by revealing that you have no idea how OBD-II is spelled, much less what it stands for.
No, he can't "just firewall the server" and "tell the few people that would affect". There are thousands of legitimate users distributed across thousands of ASes covering thousands of IP ranges which may change from day to day or even hour to hour. His server is directly connected to the core switch at the Danish Internet Exchange, where all major Danish networks exchange BGP routing information and domestic IP traffic, and its purpose is to provide a stratum-1 reference for NTP servers on these networks. To determine which IP ranges may legitimately access his server, he would need a full BGP feed and a continuously updated copy of all as-block and aut-num records in the RIPE database.
DIX is the Danish Internet Exchange, the central Internet hub in Denmark. The "customers of dix" include pretty much every ISP in Denmark, and all of *their* customers.
They didn't offer to pay for the service. They first accused him of blackmail, then offered to pay him to stop bothering them. The amount was well short of what their snafu had already cost him, and at no point did they offer to simply remove his server from the list, which is all he asked for in the first place.
A good idea, but not easily doable, since the allowed networks include most of Denmark. He would have to filter traffic based on the AS of the sender; this would require a full BGP feed and probably also a continuously updated mirror of the RIPE database.
The right way to do passive scanning is with an ethernet cable that has the tx leads removed.
Can't do that with UTP. The link pulse travels over the same wire, so the hub or switch will deactivate the port and you won't see any traffic at all. What you can do is cut the TX pin on the AUI connector when using an external tranceiver, but nobody uses those any more.
In BSD derivatives, you can up an interface without giving it an address, attach to it with bpf and set it in promiscuous mode. You'll see all the traffic on the wire, but none of it will go into the network stack and no outgoing traffic will be generated unless you do it yourself.
The 5.x branch is expected to go -STABLE with FreeBSD 5.3, which should be out some time this spring. There is a list of outstanding issues at http://www.freebsd.org/releases/5.3R/todo.html.
It's non-coding, not non-coded, and though common, the term junk DNA is highly inaccurate. The E. coli genome, for instance, contains around ten non-coding sequences whose function is known, around fifty that have been identified but whose function has not yet been determind, and almost a thousand which are thought to be functional but have not yet been confirmed experimentally. Not too shabby for an organism whose genome consists of only 4,000 to 5,000 genes, depending on the particular strain!
Do you have any evidence at all to back up your claim that reducing the size of the kernel will increase system performance? Have you run benchmarks which clearly demonstrate that a kernel compiled with the NFS_NOSERVER option performs better than a kernel built from the same sources but without that option?
I'm pretty sure that you haven't, and I'm pretty sure that if you do, you'll find that there is no appreciable difference.
Some of the procedures described in these so-called "papers" (they are really too short to merit the name) are in direct contravention of the FreeBSD Project's recommended and supported procedures.
The recommended way to build a kernel is with the 'make buildkernel' command, after a successful 'make buildworld'.
Optimization levels higher than plain -O (such as the -O2 and -O3 levels recommended by the article) are known to trigger bugs in some of the inline assembler code in the FreeBSD kernel. In previous FreeBSD versions (that shipped with older gcc versions), they were also known to trigger compiler bugs.
The TOP_TABLE_SIZE option is irrelevant to system performance. Likewise, the NFS_NOSERVER option, although it reduces the size of the kernel, does not affect performance. Conversely, none of the truly important kernel options are explained or even mentioned.
The author mentions kern.ipc.maxsockets and kern.ipc.nmbclusters, but fails to mention kern.ipc.nmbufs which must be tuned to match kern.ipc.nmbclusters (the rule of thumb is one cluster for every other mbuf). Also, the suggested values (2048) are very low - lower than the default (which is computed at boot time as a function of physical memory size) and much lower than what a busy network server will need.
Admins who are truly concerned with the performance of their FreeBSD systems are advised to read the tuning(7) manual page, as well as some of the excellent FreeBSD books available from e.g. O'Reilly.
To be accurate, WRS Never "supported" BSD - their OS is completely different. They bought Walnut Creek, a distributor of, among other things, BSD.
Actually, they bought BSDI, maker of BSD/OS, then sold off all the bits BSDI had acquired from Walnut Creek. And they did have a number of FreeBSD developers on their payroll for a while.
If I wanted my software to be TRULY and ALWAYS free that means I need a license that will prevent a corporation from taking my code and making a few alterations on it so they can pass it off as their own. The GPL protects your code from that. The BSD does not.
Noone can pass off a version of your software as their own unless you explicitly allow them to, and the BSD license explicitly forbids it just as much as the GPL does. And even if they did appropriate your software (or put a gun to your head and make you sign an exclusive license or a copyright assignment), that would not grant them control over previous versions released under the BSD license or the GPL. You can't revoke licenses you've already granted. All you can do is release new versions of your own (not anyone else's) software under a different license.
Unfortunately, the number Dan quotes for BSD accounts only for commercial sales of BSD/OS, and totally disregards sales of FreeBSD, NetBSD and OpenBSD CDs (which are orders of magnitude greater than the figure Dan quotes), not to mention non-paid-for installations. In other words, it's a meaningless number - and not only is it meaningless, but it'll spawn masses of FUD about the BSDs that we could really do without. Way to go, Dan! I expect the penguinites will give you an award for this particular exercise in creative reporting.
There's no "if (when?)" about this. According to the SciAm article (the print version, at least - I haven't read the online version), the Soviet Union already had a supercavitating torpedo (codenamed "Shkval") in 1977. Apparently, Russia, strapped for cash as always, has been selling them off; France has reputedly acquired a few to bootstrap their supercavitation research programme.
The supercavitating projectiles are still going to have a hard time changing course.
A supercavitating torpedo or shell may be fast enough that a close-range opponent doesn't have time to dodge - even better, a supersonic weapon could hit your opponent before he heard it coming, since it would travel faster than both its own noise and a sonar return.
Disregarding that situation, supercavitating weapons are still useful as "engagement breakers", i.e. weapons that, even if they do not hit the opponent, force the opponent to abandon a favorable attack position and cut loose any wire-guided torpedoes he may have launched.
Your number is off by one order of magnitude. 950 GB/day is 11.25 MBps, or 90.07 Mbps average throughput, and that's just counting the actual files transferred, not the protocol overhead. The actual figure these days is somewhere around 110 Mbps average throughput.
Agreed. It's been discussed before. I think it would greatly help matters along if you just took the latest LINT, reformatted it as you see fit, and submitted the patches. I think Java would be a good choice of language - imagine the configuration editor running as an applet somewhere on the FreeBSD web site...
Slashdot Mirror
Solenoid? Alternator? The solenoid is part of the starter assembly, bozo. It engages the starter cogwheel with the flywheel and closes the circuit that allows current to flow through the starter motor.
Gee, you almost managed to pass off as someone who knows what he's talking about, but you blew it by revealing that you have no idea how OBD-II is spelled, much less what it stands for.
No, he can't "just firewall the server" and "tell the few people that would affect". There are thousands of legitimate users distributed across thousands of ASes covering thousands of IP ranges which may change from day to day or even hour to hour. His server is directly connected to the core switch at the Danish Internet Exchange, where all major Danish networks exchange BGP routing information and domestic IP traffic, and its purpose is to provide a stratum-1 reference for NTP servers on these networks. To determine which IP ranges may legitimately access his server, he would need a full BGP feed and a continuously updated copy of all as-block and aut-num records in the RIPE database.
DIX is the Danish Internet Exchange, the central Internet hub in Denmark. The "customers of dix" include pretty much every ISP in Denmark, and all of *their* customers.
They didn't offer to pay for the service. They first accused him of blackmail, then offered to pay him to stop bothering them. The amount was well short of what their snafu had already cost him, and at no point did they offer to simply remove his server from the list, which is all he asked for in the first place.
A good idea, but not easily doable, since the allowed networks include most of Denmark. He would have to filter traffic based on the AS of the sender; this would require a full BGP feed and probably also a continuously updated mirror of the RIPE database.
Reading the fine article hasn't killed anyone yet.
For example, most of her fonts are below 1em
Your statement does not make sense. 1em is the width of the letter m in the current font.
DES
Of course PHK is a core member of the fbsd team
Poul-Henning is not a member of the core team, and hasn't been for years.
The "guy at FreeBSD who is adding wireless support", by the way, is none other than CSRG veteran Sam Leffler.
DES
The right way to do passive scanning is with an ethernet cable that has the tx leads removed.
Can't do that with UTP. The link pulse travels over the same wire, so the hub or switch will deactivate the port and you won't see any traffic at all. What you can do is cut the TX pin on the AUI connector when using an external tranceiver, but nobody uses those any more.
In BSD derivatives, you can up an interface without giving it an address, attach to it with bpf and set it in promiscuous mode. You'll see all the traffic on the wire, but none of it will go into the network stack and no outgoing traffic will be generated unless you do it yourself.
(I write network analysis software for a living)
The 5.x branch is expected to go -STABLE with FreeBSD 5.3, which should be out some time this spring. There is a list of outstanding issues at http://www.freebsd.org/releases/5.3R/todo.html.
It's non-coding, not non-coded, and though common, the term junk DNA is highly inaccurate. The E. coli genome, for instance, contains around ten non-coding sequences whose function is known, around fifty that have been identified but whose function has not yet been determind, and almost a thousand which are thought to be functional but have not yet been confirmed experimentally. Not too shabby for an organism whose genome consists of only 4,000 to 5,000 genes, depending on the particular strain!
Do you have any evidence at all to back up your claim that reducing the size of the kernel will increase system performance? Have you run benchmarks which clearly demonstrate that a kernel compiled with the NFS_NOSERVER option performs better than a kernel built from the same sources but without that option?
I'm pretty sure that you haven't, and I'm pretty sure that if you do, you'll find that there is no appreciable difference.
Some of the procedures described in these so-called "papers" (they are really too short to merit the name) are in direct contravention of the FreeBSD Project's recommended and supported procedures.
The recommended way to build a kernel is with the 'make buildkernel' command, after a successful 'make buildworld'.
Optimization levels higher than plain -O (such as the -O2 and -O3 levels recommended by the article) are known to trigger bugs in some of the inline assembler code in the FreeBSD kernel. In previous FreeBSD versions (that shipped with older gcc versions), they were also known to trigger compiler bugs.
The TOP_TABLE_SIZE option is irrelevant to system performance. Likewise, the NFS_NOSERVER option, although it reduces the size of the kernel, does not affect performance. Conversely, none of the truly important kernel options are explained or even mentioned.
The author mentions kern.ipc.maxsockets and kern.ipc.nmbclusters, but fails to mention kern.ipc.nmbufs which must be tuned to match kern.ipc.nmbclusters (the rule of thumb is one cluster for every other mbuf). Also, the suggested values (2048) are very low - lower than the default (which is computed at boot time as a function of physical memory size) and much lower than what a busy network server will need.
Admins who are truly concerned with the performance of their FreeBSD systems are advised to read the tuning(7) manual page, as well as some of the excellent FreeBSD books available from e.g. O'Reilly.
The best part of all of this would, of course, be the fact that we would all stop having to call things '*nix' or 'UNIX-like'!
The Unix trademark belongs to The Open Group, which is not affiliated with SCO.
Actually, they bought BSDI, maker of BSD/OS, then sold off all the bits BSDI had acquired from Walnut Creek. And they did have a number of FreeBSD developers on their payroll for a while.
BSDI had several full-time FreeBSD developers on their payroll when WindRiver acquired them.
Noone can pass off a version of your software as their own unless you explicitly allow them to, and the BSD license explicitly forbids it just as much as the GPL does. And even if they did appropriate your software (or put a gun to your head and make you sign an exclusive license or a copyright assignment), that would not grant them control over previous versions released under the BSD license or the GPL. You can't revoke licenses you've already granted. All you can do is release new versions of your own (not anyone else's) software under a different license.
DES
--
Unfortunately, the number Dan quotes for BSD accounts only for commercial sales of BSD/OS, and totally disregards sales of FreeBSD, NetBSD and OpenBSD CDs (which are orders of magnitude greater than the figure Dan quotes), not to mention non-paid-for installations. In other words, it's a meaningless number - and not only is it meaningless, but it'll spawn masses of FUD about the BSDs that we could really do without. Way to go, Dan! I expect the penguinites will give you an award for this particular exercise in creative reporting.
DES
--
There's no "if (when?)" about this. According to the SciAm article (the print version, at least - I haven't read the online version), the Soviet Union already had a supercavitating torpedo (codenamed "Shkval") in 1977. Apparently, Russia, strapped for cash as always, has been selling them off; France has reputedly acquired a few to bootstrap their supercavitation research programme.
DES
--
The supercavitating projectiles are still going to have a hard time changing course.
A supercavitating torpedo or shell may be fast enough that a close-range opponent doesn't have time to dodge - even better, a supersonic weapon could hit your opponent before he heard it coming, since it would travel faster than both its own noise and a sonar return.
Disregarding that situation, supercavitating weapons are still useful as "engagement breakers", i.e. weapons that, even if they do not hit the opponent, force the opponent to abandon a favorable attack position and cut loose any wire-guided torpedoes he may have launched.
DES
--
Your number is off by one order of magnitude. 950 GB/day is 11.25 MBps, or 90.07 Mbps average throughput, and that's just counting the actual files transferred, not the protocol overhead. The actual figure these days is somewhere around 110 Mbps average throughput.
--
Funny - all the ones I know use FreeBSD 8)
--
Agreed. It's been discussed before. I think it would greatly help matters along if you just took the latest LINT, reformatted it as you see fit, and submitted the patches. I think Java would be a good choice of language - imagine the configuration editor running as an applet somewhere on the FreeBSD web site...
--
I typed the wrong URL for the handbook section on kernel configuration.
--