My RPoV in one of my eyes is much, much shorter than the average, and I use it to good effect, particularly when splicing fiber optics. Don't need a magnifier; with an RPoV of around 6-8 inches (depending upon the time of day) I can see the squareness of a cleaved fiber without magnification (although as I approach 50 it's not quite as clear as it used to be, but, hey, such is life).
That of course has its downsides, like the heavy and thick lens on one eye...... to read my Droid Razr's screen, it does look a bit silly to lower my glasses and hold the screen a mere ten inches from my face, but that's the most comfortable for me..... It's almost time for bifocals, which I've put off way too long.
I'd love to have a 32 inch display with 250+ pixels per inch..... (that would be roughly an 8k display; 7680x4320, or 4320p). Everything looks smoother, and you can tell the difference when the display is close. And I'm talking within 25 inches of my face close, here; I want the screen real-estate for my multitude of open windows.....
My day job has over 200 individuals who volunteer their professional services. We have electrical engineers who help repair stuff and design stuff, librarians who help catalog our donated books and such, among a few things. Have had IT professionals run network cabling on a volunteer basis; a team of volunteers completely rewired one room with over 65 shielded CAT6 drops, from the data center all the way to the room, in one day. We have volunteers assist in educational programs, etc. Lots of opportunities.
Technically, you're mostly correct. But DOS was still there, and real-mode existed. Floppy drivers for instance, and other hardware demanded the DOS calls.
Even in Windows 95, 98, and Me 'DOS was still there.' But 'still there' and 'in control' are two different things.
But, in any case, traditional 'real mode' no longer existed, even under Windows/386 2.x and 3.x. The DOS code that was used was run under V86 mode, not real mode. Windows made calls into the DOS INT21H interface, which came right back and were at least partially handled in protect mode, with the pieces that were adequately handled by the DOS code left as they were.
Under the hood, 32-bit VxD's were slowly added to handle more and more of the OS chores in 32 bit protect mode; with WfW 3.11, 32 bit file access became probably the biggest piece to date, until Windows 95 did more of the lower level drivers, too. Even the floppy driver in older windows, if implemented in a VxD, replaced the DOS driver by hooking the DOS drivers interrupt call (using an illegal instruction trap, which, in V86 mode, traps out to a handler in 32 bit protect mode....). But the DOS floppy interface was still used; it just trapped out (thunked) to a 32-bit driver....even in Windows 9x/Me.
If Windows/386 2.0 and Windows 3.x Enhanced mode, along with Windows for Workgroups 3.11 with 32BFA, coupled with MS-DOS below, aren't full OS's, then neither are Windows 95, 98, or Me, as those are just bundles of the Windows GUI with newer MS-DOS versions. Each subsequent version replaced more and more of the 16 bit DOS code (using hooks, thunks, and other junks) with 32-bit drivers in VxD's, but the old DOS code was left in memory, in virtual-86 mode.
Again, read the book I referenced (Unauthorized Windows 95) which goes into all the gory details, and gives runnable code to prove the assertions on live Win9x (and Win/386 2.0 or Win 3.x Enhanced mode) systems.
Windows up to WfW3.11 was a user environment. MS-DOS/PC-DOS were the OS choices.
This is incorrect. Windows/386, even though it started up under MS-DOS, once the 386 VMM was running was a full-bore OS. The VMM intercepted calls to DOS, and could easily remap to 32-bit routines implemented in VxD's. It's easy enough to test yourself, just write a TSR that hooks the INT21H DOS vector, and count calls to it before and after executing win.com.
This is all exposed completely in the (long out of print) book 'Unauthorized Windows 95' by Andrew Schulman (IDG Books). The difference with Windows 95? A revamped UI, and an automatic call to win.com. In essense, DOS was the Windows/386 VMM's glorified bootloader. It's as if you went from a world where you booted to the GRUB prompt and had to manually type in the commands to load Linux to the days of grub.conf and autoloading Linux.
Windows 95, 98, and Me were all built on the Windows/386 VMM 'OS' core that used VxD's and trampolinish hackery (thunking) to get the job done. Windows NT was built on a new kernel that exposed the same API's but didn't trampoline itself into control.
Windows 9x and Me 'safe mode' is DOS with the Win32 UI, though.....
Was born in a moment of frustration with the Xenix System III getty running on a serial port of a Tandy 6000 box connected to a TRS-80 model 4 with a hires card and ANSIterm......the getty was expecting a straight ASCII reply, but kept getting what to it was garbage because the term was sending an ANSI sequence instead in response to the control codes... The gist being that the two were talking past each other and thus no communication was happening....
Man, been a long time. I thought I was the only one who had used that....and I think the last time I used that was over a year ago....
The formaldehyde absorption line at 4829.66MHz is pretty close to the low end of the UNII band at 5180MHz; even with only 40mW of power at that frequency, and taking into account the pattern, gain, and sidelobe rejection of the antennas, it is possible to desense the front end, filling in the absorption feature.
If it were an emission line (such as hydrogen at 1420) it wouldn't be as big of a deal. For instance, the methanol line at ~12GHz isn't impacted quite as much by Ku band geostationary satellites as you might think; however, the second harmonic of the upper range of the 802.11a spectrum (5.8GHz) is too close for comfort.
Fiber is used for all interbuilding links, and some intrabuilding links where the length is over 100m. The Cat5e/Cat6 is to the workstation.
We have about 75 strand miles of fiber in the ground now, linking a dozen or so buildings with 100Base-FX and 1000Base-SX/LX. A couple of random OC12 ATM multimode links round it out, since those are too long for 1000Base-LX even with mode-conditioning cords, but the bandwidth needed to be more than 100Mb/s.
We even have singlemode fiber to the two 26 meter radio telescopes' feed enclosures, for RF transmission and control, but that's mostly for lightning resistance.
As CIO at a radio astronomical observatory with instruments receiving in the 2.3GHz band, I can say that we prohibit WiFi here completely. We went as far as running shielded Cat5e and Cat6, and building the data center into a screened room to reduce the RFI. Ferrite beads on all cabling going into and out of the data center are installed as well.
I was a Red Hat beta tester at the time. The time was the beta period for Red Hat Linux 7.3. Google for that distribution; I certainly remember having significant issues going from Red Hat 7.2 to 7.3; 7.3 really really should have been called 8.0 in some respects!
To see the history, here's the KDE release for each Red Hat Linux release: RHL 6.0 -> 1.1.1pre2 (first Red Hat with KDE; piece of distro trivia: Mandrake Linux got its start as being "Red Hat 5.2 with KDE" with Mandrake Linux 5.3, which I am still running on one box to this day) RHL 6.1, 6.2, and 7.0 -> 1.1.2 RHL 7.1 -> 2.1.1 (no Red Hat with 2.0 that I could find, and I think RH took flack over that decision, IIRC) RHL 7.2 -> 2.2 RHL 7.3 -> 3.0.0 (yep, double-ought) RHL 8.0 -> 3.0.3 RHL 9 -> 3.1
Fedora Core releases to KDE releases (initial released version of KDE, not max updated version): FC1 -> 3.1.4 FC2 -> 3.2.2 FC3 -> 3.3.0 FC4 -> 3.4.0 FC5 -> 3.5.1 FC6 -> 3.5.4 F7 -> 3.5.6 F8 -> 3.5.8 F9 -> 4.0.3 F10 -> 4.1.2
I encourage you to try out the historic linux distributions for yourself and see what the issues and deals were.
Finding the sources for the historical ISO's is left as an exercise for the reader. Finding the related GNOME versions, as well as the KDE versions for other distributions is likewise left as a reader exercise, unless you want to pay me $100 per hour to research it....:-)
Oh, something more modern, such as the Distress Act of 1267 (still on the books in English Common Law and in full force in the UK)? Or the clauses of Magna Carta still active?
If you try to play an MP3, even Fedora 8 will, through 'Codec Buddy' show you how to get a legal MP3 decoder from Fluendo.
It is illegal for Fedora, based in the US, to include or provide links to (thanks to the concept of contributory infringement) MP3 decoders that do not have a patent license for MP3 decoding. The Fluendo decoder, which is a no-cost but closed source fully legal patent-licensed decoder, works very well.
Well, I have had issues before with killing under Linux,particularly if it involved CD burning and other I/O, where the process would not die, and the machine would not shut down (hung trying to umount/).
There are unkillable processes even under Linux.
And I've used Linux for quite a while (I did a floppy tape install of Soft Landing Systems back in the day, but have run Red Hat and Red Hat-derived distributions since Red Hat Linux 4 (no, not Red Hat Enterprise Linux 4, but the original Red Hat 4.0!).
Unkillable processes are far more common under Windows, but they do exist on Linux, and some of them even consume lots of resources, CPU, etc.
As they use the common technique of truncating the field degrees of freedom to a finite subset in the treatment of the Wheeler-de Witt equation,specifically, by only treating the radial R, they limit themselves to spherical domain walls instead of lenticular domain walls. A rotating mass in collapse tends lenticular (although that is a vast oversimplification), so the short answer is that they do not really treat the case of rotating masses.
Likewise, they are dealing only with domain walls of zero thickness.
However, this does adequately describe any given spherical domain wall of uniform density; nonspherical domain walls can be treated as a set of spherical domain walls with nonuniform density. However, I'm not sure if the tensor describing a nonuniformly dense domain wall is even solvable with current techniques or not; a lenticular tensor may be easier, but as this is at the very grey edge of my math skills, I haven't the foggiest idea if that is true for the general treatment of the Wheeler-de Witt equation.
Reading the preprint is rather informative; while the math is a little beyond my grasp, the concepts are not, and their 'conclusions' are very enlightening, as they detail problems in their analysis that suggest possible issues.
First, they deal with the lack of rigorous treatment of unspecific backreaction, and state that until such treament is available the final fate of the collapsing object is indeterminate.
Second, they deal with their assumptions and the possible changes in their results due to their assumptions (the zero thickness domain wall, the domain wall being spherical and of uniform density, their truncation of superspace to minisuperspace, the lack of allowance for possible third quantization due to annihilation and creation of domain walls, their Langrangian not breaking down near the Shwarzschild horizon, etc, all of which are in the preprint).
Slashdot Mirror
My RPoV in one of my eyes is much, much shorter than the average, and I use it to good effect, particularly when splicing fiber optics. Don't need a magnifier; with an RPoV of around 6-8 inches (depending upon the time of day) I can see the squareness of a cleaved fiber without magnification (although as I approach 50 it's not quite as clear as it used to be, but, hey, such is life).
That of course has its downsides, like the heavy and thick lens on one eye...... to read my Droid Razr's screen, it does look a bit silly to lower my glasses and hold the screen a mere ten inches from my face, but that's the most comfortable for me..... It's almost time for bifocals, which I've put off way too long.
I'd love to have a 32 inch display with 250+ pixels per inch..... (that would be roughly an 8k display; 7680x4320, or 4320p). Everything looks smoother, and you can tell the difference when the display is close. And I'm talking within 25 inches of my face close, here; I want the screen real-estate for my multitude of open windows.....
See https://en.wikipedia.org/wiki/List_of_displays_by_pixel_density
All definitions are, by definition, artificially constructed.
If you have IRIX sets, go to Nekochan.net
That's also why RPM will not let a package overwrite another package's files. Wow, what a concept.
Deja vu: AKA the Loki installer. Still used by CodeWeavers for their distribution independent CrossOver packages. See http://en.wikipedia.org/wiki/Loki_Software and http://icculus.org/loki_setup/ which is the installer's home after Loki Software's closing.
My day job has over 200 individuals who volunteer their professional services. We have electrical engineers who help repair stuff and design stuff, librarians who help catalog our donated books and such, among a few things. Have had IT professionals run network cabling on a volunteer basis; a team of volunteers completely rewired one room with over 65 shielded CAT6 drops, from the data center all the way to the room, in one day. We have volunteers assist in educational programs, etc. Lots of opportunities.
There are even a few of our volunteers who have earned various levels of the Presidential Volunteer Service Awards ( http://www.presidentialserviceawards.gov/ ).
And Windows/386 made no real-mode calls?
Technically, you're mostly correct. But DOS was still there, and real-mode existed. Floppy drivers for instance, and other hardware demanded the DOS calls.
Even in Windows 95, 98, and Me 'DOS was still there.' But 'still there' and 'in control' are two different things.
But, in any case, traditional 'real mode' no longer existed, even under Windows/386 2.x and 3.x. The DOS code that was used was run under V86 mode, not real mode. Windows made calls into the DOS INT21H interface, which came right back and were at least partially handled in protect mode, with the pieces that were adequately handled by the DOS code left as they were.
Under the hood, 32-bit VxD's were slowly added to handle more and more of the OS chores in 32 bit protect mode; with WfW 3.11, 32 bit file access became probably the biggest piece to date, until Windows 95 did more of the lower level drivers, too. Even the floppy driver in older windows, if implemented in a VxD, replaced the DOS driver by hooking the DOS drivers interrupt call (using an illegal instruction trap, which, in V86 mode, traps out to a handler in 32 bit protect mode....). But the DOS floppy interface was still used; it just trapped out (thunked) to a 32-bit driver....even in Windows 9x/Me.
If Windows/386 2.0 and Windows 3.x Enhanced mode, along with Windows for Workgroups 3.11 with 32BFA, coupled with MS-DOS below, aren't full OS's, then neither are Windows 95, 98, or Me, as those are just bundles of the Windows GUI with newer MS-DOS versions. Each subsequent version replaced more and more of the 16 bit DOS code (using hooks, thunks, and other junks) with 32-bit drivers in VxD's, but the old DOS code was left in memory, in virtual-86 mode.
Again, read the book I referenced (Unauthorized Windows 95) which goes into all the gory details, and gives runnable code to prove the assertions on live Win9x (and Win/386 2.0 or Win 3.x Enhanced mode) systems.
This is about OSes.
Windows up to WfW3.11 was a user environment. MS-DOS/PC-DOS were the OS choices.
This is incorrect. Windows/386, even though it started up under MS-DOS, once the 386 VMM was running was a full-bore OS. The VMM intercepted calls to DOS, and could easily remap to 32-bit routines implemented in VxD's. It's easy enough to test yourself, just write a TSR that hooks the INT21H DOS vector, and count calls to it before and after executing win.com.
This is all exposed completely in the (long out of print) book 'Unauthorized Windows 95' by Andrew Schulman (IDG Books). The difference with Windows 95? A revamped UI, and an automatic call to win.com. In essense, DOS was the Windows/386 VMM's glorified bootloader. It's as if you went from a world where you booted to the GRUB prompt and had to manually type in the commands to load Linux to the days of grub.conf and autoloading Linux.
Windows 95, 98, and Me were all built on the Windows/386 VMM 'OS' core that used VxD's and trampolinish hackery (thunking) to get the job done. Windows NT was built on a new kernel that exposed the same API's but didn't trampoline itself into control.
Windows 9x and Me 'safe mode' is DOS with the Win32 UI, though.....
Hrmph. Shouldn't the tagline be:
ASCII stupid question, getty stupid ANSI.
Was born in a moment of frustration with the Xenix System III getty running on a serial port of a Tandy 6000 box connected to a TRS-80 model 4 with a hires card and ANSIterm......the getty was expecting a straight ASCII reply, but kept getting what to it was garbage because the term was sending an ANSI sequence instead in response to the control codes... The gist being that the two were talking past each other and thus no communication was happening....
Man, been a long time. I thought I was the only one who had used that....and I think the last time I used that was over a year ago....
I remember those flamewars.... Almost as bad as the Great Renaming.
Not at this time, unfortunately.
The formaldehyde absorption line at 4829.66MHz is pretty close to the low end of the UNII band at 5180MHz; even with only 40mW of power at that frequency, and taking into account the pattern, gain, and sidelobe rejection of the antennas, it is possible to desense the front end, filling in the absorption feature.
If it were an emission line (such as hydrogen at 1420) it wouldn't be as big of a deal. For instance, the methanol line at ~12GHz isn't impacted quite as much by Ku band geostationary satellites as you might think; however, the second harmonic of the upper range of the 802.11a spectrum (5.8GHz) is too close for comfort.
See http://www.astrosurf.com/luxorion/radioastronomy-lines.htm for a small list of interesting spectral lines.
Fiber is used for all interbuilding links, and some intrabuilding links where the length is over 100m. The Cat5e/Cat6 is to the workstation.
We have about 75 strand miles of fiber in the ground now, linking a dozen or so buildings with 100Base-FX and 1000Base-SX/LX. A couple of random OC12 ATM multimode links round it out, since those are too long for 1000Base-LX even with mode-conditioning cords, but the bandwidth needed to be more than 100Mb/s.
We even have singlemode fiber to the two 26 meter radio telescopes' feed enclosures, for RF transmission and control, but that's mostly for lightning resistance.
RFI.
As CIO at a radio astronomical observatory with instruments receiving in the 2.3GHz band, I can say that we prohibit WiFi here completely. We went as far as running shielded Cat5e and Cat6, and building the data center into a screened room to reduce the RFI. Ferrite beads on all cabling going into and out of the data center are installed as well.
Wired Ethernet is the only thing working here.
I successfully upgraded a server from RH 4.2 to 5.1 long ago, and while it did have a few buglets, for the most part it worked.
I did.
I was a Red Hat beta tester at the time. The time was the beta period for Red Hat Linux 7.3. Google for that distribution; I certainly remember having significant issues going from Red Hat 7.2 to 7.3; 7.3 really really should have been called 8.0 in some respects!
To see the history, here's the KDE release for each Red Hat Linux release:
RHL 6.0 -> 1.1.1pre2 (first Red Hat with KDE; piece of distro trivia: Mandrake Linux got its start as being "Red Hat 5.2 with KDE" with Mandrake Linux 5.3, which I am still running on one box to this day)
RHL 6.1, 6.2, and 7.0 -> 1.1.2
RHL 7.1 -> 2.1.1 (no Red Hat with 2.0 that I could find, and I think RH took flack over that decision, IIRC)
RHL 7.2 -> 2.2
RHL 7.3 -> 3.0.0 (yep, double-ought)
RHL 8.0 -> 3.0.3
RHL 9 -> 3.1
Fedora Core releases to KDE releases (initial released version of KDE, not max updated version):
FC1 -> 3.1.4
FC2 -> 3.2.2
FC3 -> 3.3.0
FC4 -> 3.4.0
FC5 -> 3.5.1
FC6 -> 3.5.4
F7 -> 3.5.6
F8 -> 3.5.8
F9 -> 4.0.3
F10 -> 4.1.2
I encourage you to try out the historic linux distributions for yourself and see what the issues and deals were.
Finding the sources for the historical ISO's is left as an exercise for the reader. Finding the related GNOME versions, as well as the KDE versions for other distributions is likewise left as a reader exercise, unless you want to pay me $100 per hour to research it.... :-)
Oh, something more modern, such as the Distress Act of 1267 (still on the books in English Common Law and in full force in the UK)? Or the clauses of Magna Carta still active?
Harumph.
Did it in less lines, in VAX Pascal no less, in 1985.
10:54
Getting from some I2 mirrors (we're on I2 here). Mirrors should open up soon enough.
Nah, they write them in INTERCAL. With lots of COME FROMs.
If you try to play an MP3, even Fedora 8 will, through 'Codec Buddy' show you how to get a legal MP3 decoder from Fluendo.
It is illegal for Fedora, based in the US, to include or provide links to (thanks to the concept of contributory infringement) MP3 decoders that do not have a patent license for MP3 decoding. The Fluendo decoder, which is a no-cost but closed source fully legal patent-licensed decoder, works very well.
Well, I have had issues before with killing under Linux,particularly if it involved CD burning and other I/O, where the process would not die, and the machine would not shut down (hung trying to umount /).
There are unkillable processes even under Linux.
And I've used Linux for quite a while (I did a floppy tape install of Soft Landing Systems back in the day, but have run Red Hat and Red Hat-derived distributions since Red Hat Linux 4 (no, not Red Hat Enterprise Linux 4, but the original Red Hat 4.0!).
Unkillable processes are far more common under Windows, but they do exist on Linux, and some of them even consume lots of resources, CPU, etc.
Indeed. I think I found Slashdot in March 1998, but it was a while before I registered. Found Slashdot and Freshmeat the same day.
Somebody took a sledgehammer to it.
As they use the common technique of truncating the field degrees of freedom to a finite subset in the treatment of the Wheeler-de Witt equation,specifically, by only treating the radial R, they limit themselves to spherical domain walls instead of lenticular domain walls. A rotating mass in collapse tends lenticular (although that is a vast oversimplification), so the short answer is that they do not really treat the case of rotating masses.
Likewise, they are dealing only with domain walls of zero thickness.
However, this does adequately describe any given spherical domain wall of uniform density; nonspherical domain walls can be treated as a set of spherical domain walls with nonuniform density. However, I'm not sure if the tensor describing a nonuniformly dense domain wall is even solvable with current techniques or not; a lenticular tensor may be easier, but as this is at the very grey edge of my math skills, I haven't the foggiest idea if that is true for the general treatment of the Wheeler-de Witt equation.
Reading the preprint is rather informative; while the math is a little beyond my grasp, the concepts are not, and their 'conclusions' are very enlightening, as they detail problems in their analysis that suggest possible issues.
First, they deal with the lack of rigorous treatment of unspecific backreaction, and state that until such treament is available the final fate of the collapsing object is indeterminate.
Second, they deal with their assumptions and the possible changes in their results due to their assumptions (the zero thickness domain wall, the domain wall being spherical and of uniform density, their truncation of superspace to minisuperspace, the lack of allowance for possible third quantization due to annihilation and creation of domain walls, their Langrangian not breaking down near the Shwarzschild horizon, etc, all of which are in the preprint).
It is quite a fascinating read.