The object probably goes too fast to capture into orbit, but it would be nice to have a cheap source of minerals that could be sent down to earth in carefully planned decents.
BSD is dead, I forgot about that when I installed it on my 5 local machines years ago. Silly me, how could I miss something like that? I guess I forgot that Finux is so l33t (like you) because it has less user than Windows. Then the Finux user discovers something with less users than even Finiux, and it has a license that is non-virus like. Oh no.... not something more free and stable than Finux, it couldn't be, it just can't exist... the World is in collision, you had better sink into denial and just say "BSD is dying". Yes, Yes... thats it, it doesn't exist, it cannot be. Close your eyes, run around in circles screaming "BSD is dead", I'm sure you will convince yourself of it given enough time.
Since BSD has been dying for 5 years now, and gainning a cult of devil (daemon) worshipers, it must be evil. Yes, that's it! It is the work of evil, like microsoft. Yes, anything that is not Finux must be bad, right? I mean, it has a license that actually is free. This must be a trick! nothing is free as in "free speach", and free as in "cost nothing". Why Finux is only free as in "cost nothing", but requires any modifcations to go back to the borg collective... er.. I mean the Free Soft Ware Foundation. Besides, The mascot is a daemon, and it has cute little horns, and that trident. Finux has a penguin, which is the mascot because Linus was travelling to Brazil in 94 and got biten by a cute little penguin. There for BSD is dying, yes... (running around in circles), BSD is dead.
Good for you, have a cookie from the jar. I did manage to crack WEP on several different AP's, but I probably do this stuff more than you? =)
I Would estimate that of the hundreds of AP's I have surfed, only 30% bother to enable WEP or any sort of seciurty such as mac/ip filters. Of Those AP's that did enable WEP, only a few were a problem for me. For example, one AP had some sort of round-robin WEP key exchange that must have changed before I got enough packets, another was using IPSEC over WEP (I cracked the WEP), and more recently I have found folks actually using the 128/156 WEP encryption (slow). I use the bsd-airtools BTW, which uses a very fast method to crack WEP.
This is wonderfull news. Now with my DC-to-AC car power addapter, I can plug my Xbox into the extra DC outlet in my SUV and ride around and game on other people's internet connections. Even more interesting is the notion that I can probably now intercept other peoples game packets form my cozy parking spot in front of their house! Who know, I might even be able to get a free live subscription by hijacking another persons packets over the 802.11 medium. Games are awsome at generating lots of packets too, so I can easily capture one million packets (the suggested amount for WEP cracking) if they get any ideas of enabling encryption. It took me all of 7 seconds to crack the WEP encryption my neighbors used once I had enough packets logged (5 or 6 hours). I cannot wait for this new toy to hit the shelves. I can finally replace that old laptop (running freebsd) which sits atop the xbox, and acts as a IPless bridge over wifi. Ya!
I would be willing to help in this. I can write in C, and it really isn't that trivial of functionallity once I think about it. But we must realize that portupgrade is a suite of tools, and we would have to do them all. It would be nice to add some XML support to portupgrade, and the ports system in general as Jordan Hubard once suggested. Anyways, it seems easy to me to parse the pkgdb and act upon it. If your still interested, let me know.. you would have at least one person in your corner. =)
I admit you have an intersting perspective, and i would point out that you can build your system without kerberos via make.conf options. Same for Sendmail, etc...
The thing that tweaks me is that portupgrade should be part of the base system. Portupgrade and friends should be writen in something aside from ruby (becuse we dont' want ruby in base). It is probably the most usefull and powerfull package/port managment tool ever created since the freebsd ports is already the best package system in all of open source. FreeBSD ports is always immitated, yet never replicated in full glory. It nice that portupgrade traces down dependancies automatically (forward, or reverse), and can cleanout stale lib's and such.
Dude, you cannot be serrious, right? Nobody writes shell scripts in csh or tcsh because it is well known that they are both utterly unsuitable for shell scripting. And if your talking about a hetrogenious environment, then you should have known to script in the POSIX shell which is sh. If you want your scripts to work anywhere, you would never write the script in bash, csh, or tcsh. KSH, and SH are the only two real contenders for shell scripting. Anything above the ability of shell scripting is the realm of perl, expect, tcl, etc. TCSH is a users shell because its focus is on quick intuitive user input. TCSH is just like BASH in the way it is user friendly. The issue here is the fact that Finux ships with BASH as the root's shell, and all the BSD's (OS X included) have csh heritige starting with Bill Joy (the guy who first intigrated TCP/IP into UNIX, and is the CTO of SUN) when he inventd csh to replace sh, which sucks to use. Since tcsh replaces csh all the bsd's use that. For a nearly a decade (the 1980's) CSH was the shell of choise for unix admins. In that time the notion of one shell for typing in commands, and one for scripts. Then Korn wrote ksh to replace sh for portable scripting, but it was also a super good shell for user input, and it became the dominant shell for many years (88 to 95). Enter the FSF who wanted a shell that was GPL and as userfull as TCSH and KSH. In reality BASH is as usable as TCSH, yet less portable than any other shell for scripting, csh/tcsh excluded. In general, it seems that most Finux users have zero experience with any other shell aside from BASH since Finux is typically their first, and only ecounter with a Unix-like operating system, less they seek the enlightenment of *BSD. What is observed is that many folks who do break out of their Finux trainning wheels, still need to use BASH because of the constant typo's and eronious user-input, which they instinctivly go to the back-arrow. To seasoned Unix admins this is a quick way to identify inexperienced junior admins (aka folks who have to use BASH).
That is the skinny on shell portability, and why we are at the point we are with shells.
Diamond Memory Modules (aka DMM) would have to be used with these things I suspect. For such a jump in speed would also require a similare jump in memory capacity, and speed. Saddly I don't know how this tech would equate to memory density, but if anything the increased speed would be nice.
Secondly, I remember seeing something on television once that described the multi-national diamon cartel DeBears (spelling?) as attempting to halt the commercialization of artificial diamons. Certainly natural diamons have defects and are not flat. Aledgedly The cartel somehow was able to stop the production of artifical diamons for the purpose of jewels, but in the proces they got certain rights to the technology of growing diamons. GTE developed the technology in the 80's and I don't think it ever got past the application of diamond tipped drill bits. </rant>
So why is it sometimes called ``Linux emulation''? To make it hard to sell FreeBSD! Really, it is because the historical implementation was done at a time when there was really no word other than that to describe what was going on; saying that FreeBSD ran Linux binaries was not true, if you did not compile the code in or load a module, and there needed to be a word to describe what was being loaded--hence ``the Linux emulator''.
I think that pretty much says it all. It is, for lack of a better word, an emulator even thought it's just manipulating of the she-bang (magic number) at the begining of the binary.
I think you are all wrong. Reminds me of the town fool. Everyone knows your a fool, but when you open your mouth you simultaniously remove any doubt.
BSD* has no java port. Yes it does.
BSD* does no run an emulated Linux Java virtual machine. Instead it run it as a normal process and maps Linux calls to simular BSD calls. FreeBSD has a linux emulation layer, for running linux applications, and so the linux apps think they are talking to a linux kernel and userland. FreeBSD can, and many people do, run the linux JDK under emulation. In fact, to compile the native version of JDK on FreeBSD you have to boot-strap it with the linux version (java requires java to install). Afterwards folks can use the native version to build the native BSD version again. BTW - the process of mapping linux syscalls to their BSD counter part is called emulation.
I'd imagine that if NetBSD and OpenBSD don't already have this ability it will be a matter of time as the BSD's share much between each other.
Silly didn't you know that FreeBSD is stealling this from NetBSD's dynamic world? Well they are. FreeBSD has also taken the idea of a/rescue incase one of the libs that is dynamicly linked by (say init) is damaged. This was also a NetBSD idea. I guess that leaves OpenBSD to make the changes, but they probably think dynamic bins is insecure or some shit because an attacker would simply replace a lib that contains harmfull code-fu.
I picture in my mind Mr. Spacely reaching thru the video phone to grab Jetson by the collar while yelling. Why hasn't this technologie matured? Think it might have anything to do with people not wanting to face their boss while calling in sick? naw.. it couldn't be that..
It really depends if your a pesimist, or an optimist. Yes 3 units of 12 is indeed 25%, and since it is 3 units over 12 to 15 it could be seen as an additional 25% extra time. The more correct way to look at it is from the point of view for the number 15. aka the boot was an entire 1/5 faster without dynamic bins.
Besides, there have also been improvements in caching libs in conjunction with linking so that dynamic bin's always load faster. It could also be possible to make certain/bin and/sbin stuff static, but thats what/rescue is for with the crunched bins. Besides, this will only lead to a more optimised ld program and linking system there after. Not having the entire bulk of libc repliated allover the place in/bin and/sbin is entirly acceptible to me. Architecturally speaking that is a big faux pax to leave such a clutter. This is why elf was devised in the first place, and slow to implement Operating Environments is partly to blame for the hindering of cool features like dynamic linking tricks such as thosed used in pam and nss. This is, after all, the reason we have libraries.
I'm actually friends with the guy that created wifibsd, and we both work on miniturization of freebsd, and we are both into wireless stuff. We hangout in IRC and are basically the resident 802.11 thugs. So yes, you could say I have an inside knowledge. Truth be told, Yazzy (aka Martin Jessa) finished this last night, posted a blurb in #freebsd, and then one of the lurkers posted to slashdot. So both theories are true: I got scarry knowledge of minibsd, and inside knowledge of wifibsd. What is more scarry is how the BSD community is so tightly bound together.
Would the use of electron bombardment cause the classical quantum conundrum where direct observation of particles affects their quantum state, and I suppose their non-quantum existance? I'm actually suprised this hasn't happened already. Electron microscopes normally have to look at very still stuff, and a chemical recation isn't still by any measure. But photographing moving stuff would seem to be the next logical step (still pictures, motion pictures). I'd like to see some microscopic movies of fire (combustion) in action!;)
I wonder what would happen if a anti-blackhole collided with a normal blackhole. Would they eat eachother up instantly, or blow up? Would the bigger blackhole simply become that much less massive? Or what about dark-matter coming in contact with anti-matter, is that even possible?
I wasn't that wrong, actually i wasn't at all, except forthe aspect of carbom-dioxide compared to carbon-monoxide and the different ways they kill humans. At anyrate, at my former job I ran some SGI Onyx machines (the size of refigerators) which had a auto-cut-off feature to self-die if the temperature rised above 112F, which was easy for those machines unless you had a swam cooler pointed directly at it. The same was true of the big honking HP t-600. It seems that only i396 machines have the abillity to over-heat accidentally and unknowingly yet keep processing.
Allas, I have thought of a solution tothe issue. Simply watter cool all computers! Either submerse the mainboards in mineral oil (non-electrolyte/non-conductive) which pool-pumps to circulate the fluid. Or we can have a closed water cooling system which requires pumps, even a centrally located pump if the hardware vendors came to standard on the pump interfaces. In the later system we could simply move in treadmills durring a power outage, and have the IT system admin excerrsize on the treadmills wich would be attached to the standardized central pump system to circulate the water. Human rodents in a spin-wheel! har har
indeed your correct, and I'm wrong... well sorta. I base my somewhat uninformed comment on the fact that there is lore about people who put dry-ice in a standard cooler to keep icecream from melting on a cross-country drive. As the lore goes: the couple with the cooler in the back seat suffer form a plauge of problems the entire trip. The man has a constant headache, and the woman is constantly sleepy. It turns out the dryice was the issue in the confined space. The dryice evaporates, and the humans breath it in, and eventually they got into an auto accident. So I fear that using dryice in a confined space like a data center will indeed cool it down, there needs to be a way to oxygenate the same air too, possibly scrub the CO out or the humans will suffer.
I'd create a virtual-server for each timezone in question, it could have its own ntp tools managing the time, and its own cron to be the timer. Keep things nice and neat. In freebssd at least this could be done in a jail.
Slashdot Mirror
The object probably goes too fast to capture into orbit, but it would be nice to have a cheap source of minerals that could be sent down to earth in carefully planned decents.
oh ya.....
... thats it, it doesn't exist, it cannot be. Close your eyes, run around in circles screaming "BSD is dead", I'm sure you will convince yourself of it given enough time.
BSD is dead, I forgot about that when I installed it on my 5 local machines years ago. Silly me, how could I miss something like that? I guess I forgot that Finux is so l33t (like you) because it has less user than Windows. Then the Finux user discovers something with less users than even Finiux, and it has a license that is non-virus like. Oh no.... not something more free and stable than Finux, it couldn't be, it just can't exist... the World is in collision, you had better sink into denial and just say "BSD is dying". Yes, Yes
Since BSD has been dying for 5 years now, and gainning a cult of devil (daemon) worshipers, it must be evil. Yes, that's it! It is the work of evil, like microsoft. Yes, anything that is not Finux must be bad, right? I mean, it has a license that actually is free. This must be a trick! nothing is free as in "free speach", and free as in "cost nothing". Why Finux is only free as in "cost nothing", but requires any modifcations to go back to the borg collective... er.. I mean the Free Soft Ware Foundation. Besides, The mascot is a daemon, and it has cute little horns, and that trident. Finux has a penguin, which is the mascot because Linus was travelling to Brazil in 94 and got biten by a cute little penguin. There for BSD is dying, yes... (running around in circles), BSD is dead.
nope, BSD-Airtools uses some tricks to go faster, enough so that I wouldn't use anything else. BAT has its own magic to reject non-weak packets.
Technicly this is a dup of a previous technology.
Good for you, have a cookie from the jar. I did manage to crack WEP on several different AP's, but I probably do this stuff more than you? =)
I Would estimate that of the hundreds of AP's I have surfed, only 30% bother to enable WEP or any sort of seciurty such as mac/ip filters. Of Those AP's that did enable WEP, only a few were a problem for me. For example, one AP had some sort of round-robin WEP key exchange that must have changed before I got enough packets, another was using IPSEC over WEP (I cracked the WEP), and more recently I have found folks actually using the 128/156 WEP encryption (slow). I use the bsd-airtools BTW, which uses a very fast method to crack WEP.
This is wonderfull news. Now with my DC-to-AC car power addapter, I can plug my Xbox into the extra DC outlet in my SUV and ride around and game on other people's internet connections. Even more interesting is the notion that I can probably now intercept other peoples game packets form my cozy parking spot in front of their house! Who know, I might even be able to get a free live subscription by hijacking another persons packets over the 802.11 medium. Games are awsome at generating lots of packets too, so I can easily capture one million packets (the suggested amount for WEP cracking) if they get any ideas of enabling encryption. It took me all of 7 seconds to crack the WEP encryption my neighbors used once I had enough packets logged (5 or 6 hours). I cannot wait for this new toy to hit the shelves. I can finally replace that old laptop (running freebsd) which sits atop the xbox, and acts as a IPless bridge over wifi. Ya!
I can be found on irc.freenode.net, in the obvious place (#freebsd). My nickname is "masta". I'll look at your site to find an email.
I would be willing to help in this. I can write in C, and it really isn't that trivial of functionallity once I think about it. But we must realize that portupgrade is a suite of tools, and we would have to do them all. It would be nice to add some XML support to portupgrade, and the ports system in general as Jordan Hubard once suggested. Anyways, it seems easy to me to parse the pkgdb and act upon it. If your still interested, let me know.. you would have at least one person in your corner. =)
I admit you have an intersting perspective, and i would point out that you can build your system without kerberos via make.conf options. Same for Sendmail, etc...
The thing that tweaks me is that portupgrade should be part of the base system. Portupgrade and friends should be writen in something aside from ruby (becuse we dont' want ruby in base). It is probably the most usefull and powerfull package/port managment tool ever created since the freebsd ports is already the best package system in all of open source. FreeBSD ports is always immitated, yet never replicated in full glory. It nice that portupgrade traces down dependancies automatically (forward, or reverse), and can cleanout stale lib's and such.
I did read it. I got it from that book. It tickles the nerves of certain Finux using zelots, like yourself (I'm guessing).
Dude, you cannot be serrious, right? Nobody writes shell scripts in csh or tcsh because it is well known that they are both utterly unsuitable for shell scripting. And if your talking about a hetrogenious environment, then you should have known to script in the POSIX shell which is sh. If you want your scripts to work anywhere, you would never write the script in bash, csh, or tcsh. KSH, and SH are the only two real contenders for shell scripting. Anything above the ability of shell scripting is the realm of perl, expect, tcl, etc. TCSH is a users shell because its focus is on quick intuitive user input. TCSH is just like BASH in the way it is user friendly. The issue here is the fact that Finux ships with BASH as the root's shell, and all the BSD's (OS X included) have csh heritige starting with Bill Joy (the guy who first intigrated TCP/IP into UNIX, and is the CTO of SUN) when he inventd csh to replace sh, which sucks to use. Since tcsh replaces csh all the bsd's use that. For a nearly a decade (the 1980's) CSH was the shell of choise for unix admins. In that time the notion of one shell for typing in commands, and one for scripts. Then Korn wrote ksh to replace sh for portable scripting, but it was also a super good shell for user input, and it became the dominant shell for many years (88 to 95). Enter the FSF who wanted a shell that was GPL and as userfull as TCSH and KSH. In reality BASH is as usable as TCSH, yet less portable than any other shell for scripting, csh/tcsh excluded. In general, it seems that most Finux users have zero experience with any other shell aside from BASH since Finux is typically their first, and only ecounter with a Unix-like operating system, less they seek the enlightenment of *BSD. What is observed is that many folks who do break out of their Finux trainning wheels, still need to use BASH because of the constant typo's and eronious user-input, which they instinctivly go to the back-arrow. To seasoned Unix admins this is a quick way to identify inexperienced junior admins (aka folks who have to use BASH).
That is the skinny on shell portability, and why we are at the point we are with shells.
Diamond Memory Modules (aka DMM) would have to be used with these things I suspect. For such a jump in speed would also require a similare jump in memory capacity, and speed. Saddly I don't know how this tech would equate to memory density, but if anything the increased speed would be nice.
Secondly, I remember seeing something on television once that described the multi-national diamon cartel DeBears (spelling?) as attempting to halt the commercialization of artificial diamons. Certainly natural diamons have defects and are not flat. Aledgedly The cartel somehow was able to stop the production of artifical diamons for the purpose of jewels, but in the proces they got certain rights to the technology of growing diamons. GTE developed the technology in the 80's and I don't think it ever got past the application of diamond tipped drill bits.
</rant>
http://www.freebsd.org/doc/en_US.ISO8859-1/book
Notice the "emu" in the linkage?
I think that pretty much says it all. It is, for lack of a better word, an emulator even thought it's just manipulating of the she-bang (magic number) at the begining of the binary.
I think you are all wrong.
Reminds me of the town fool. Everyone knows your a fool, but when you open your mouth you simultaniously remove any doubt.
BSD* has no java port.
Yes it does.
BSD* does no run an emulated Linux Java virtual machine. Instead it run it as a normal process
and maps Linux calls to simular BSD calls.
FreeBSD has a linux emulation layer, for running linux applications, and so the linux apps think they are talking to a linux kernel and userland. FreeBSD can, and many people do, run the linux JDK under emulation. In fact, to compile the native version of JDK on FreeBSD you have to boot-strap it with the linux version (java requires java to install). Afterwards folks can use the native version to build the native BSD version again. BTW - the process of mapping linux syscalls to their BSD counter part is called emulation.
I'd imagine that if NetBSD and OpenBSD don't already have this ability it will be a matter of time as the BSD's share much between each other.
/rescue incase one of the libs that is dynamicly linked by (say init) is damaged. This was also a NetBSD idea. I guess that leaves OpenBSD to make the changes, but they probably think dynamic bins is insecure or some shit because an attacker would simply replace a lib that contains harmfull code-fu.
Silly didn't you know that FreeBSD is stealling this from NetBSD's dynamic world? Well they are. FreeBSD has also taken the idea of a
I picture in my mind Mr. Spacely reaching thru the video phone to grab Jetson by the collar while yelling. Why hasn't this technologie matured? Think it might have anything to do with people not wanting to face their boss while calling in sick? naw.. it couldn't be that..
It really depends if your a pesimist, or an optimist. Yes 3 units of 12 is indeed 25%, and since it is 3 units over 12 to 15 it could be seen as an additional 25% extra time. The more correct way to look at it is from the point of view for the number 15. aka the boot was an entire 1/5 faster without dynamic bins.
/bin and /sbin stuff static, but thats what /rescue is for with the crunched bins. Besides, this will only lead to a more optimised ld program and linking system there after. Not having the entire bulk of libc repliated allover the place in /bin and /sbin is entirly acceptible to me. Architecturally speaking that is a big faux pax to leave such a clutter. This is why elf was devised in the first place, and slow to implement Operating Environments is partly to blame for the hindering of cool features like dynamic linking tricks such as thosed used in pam and nss. This is, after all, the reason we have libraries.
Besides, there have also been improvements in caching libs in conjunction with linking so that dynamic bin's always load faster. It could also be possible to make certain
I'm actually friends with the guy that created wifibsd, and we both work on miniturization of freebsd, and we are both into wireless stuff. We hangout in IRC and are basically the resident 802.11 thugs. So yes, you could say I have an inside knowledge. Truth be told, Yazzy (aka Martin Jessa) finished this last night, posted a blurb in #freebsd, and then one of the lurkers posted to slashdot. So both theories are true: I got scarry knowledge of minibsd, and inside knowledge of wifibsd. What is more scarry is how the BSD community is so tightly bound together.
The project is based on minibsd, which is based on freebsd.
Would the use of electron bombardment cause the classical quantum conundrum where direct observation of particles affects their quantum state, and I suppose their non-quantum existance? I'm actually suprised this hasn't happened already. Electron microscopes normally have to look at very still stuff, and a chemical recation isn't still by any measure. But photographing moving stuff would seem to be the next logical step (still pictures, motion pictures). I'd like to see some microscopic movies of fire (combustion) in action! ;)
I wonder what would happen if a anti-blackhole collided with a normal blackhole. Would they eat eachother up instantly, or blow up? Would the bigger blackhole simply become that much less massive? Or what about dark-matter coming in contact with anti-matter, is that even possible?
I wasn't that wrong, actually i wasn't at all, except forthe aspect of carbom-dioxide compared to carbon-monoxide and the different ways they kill humans. At anyrate, at my former job I ran some SGI Onyx machines (the size of refigerators) which had a auto-cut-off feature to self-die if the temperature rised above 112F, which was easy for those machines unless you had a swam cooler pointed directly at it. The same was true of the big honking HP t-600. It seems that only i396 machines have the abillity to over-heat accidentally and unknowingly yet keep processing.
Allas, I have thought of a solution tothe issue. Simply watter cool all computers! Either submerse the mainboards in mineral oil (non-electrolyte/non-conductive) which pool-pumps to circulate the fluid. Or we can have a closed water cooling system which requires pumps, even a centrally located pump if the hardware vendors came to standard on the pump interfaces. In the later system we could simply move in treadmills durring a power outage, and have the IT system admin excerrsize on the treadmills wich would be attached to the standardized central pump system to circulate the water. Human rodents in a spin-wheel! har har
indeed your correct, and I'm wrong... well sorta. I base my somewhat uninformed comment on the fact that there is lore about people who put dry-ice in a standard cooler to keep icecream from melting on a cross-country drive. As the lore goes: the couple with the cooler in the back seat suffer form a plauge of problems the entire trip. The man has a constant headache, and the woman is constantly sleepy. It turns out the dryice was the issue in the confined space. The dryice evaporates, and the humans breath it in, and eventually they got into an auto accident. So I fear that using dryice in a confined space like a data center will indeed cool it down, there needs to be a way to oxygenate the same air too, possibly scrub the CO out or the humans will suffer.
I'd create a virtual-server for each timezone in question, it could have its own ntp tools managing the time, and its own cron to be the timer. Keep things nice and neat. In freebssd at least this could be done in a jail.