are you saying you don't stream your logs across the network/frame relay to another site where they are permanently stored and monitored by unrelated personnel? If you have seperate admin teams, make them in charge of other people's logs (and vice-versa). It's like a checks and balances system.
Honestly... just re-copying a digital linear tape every 10 years is a safer bet than any other technology or solution.
DLT tapes are nearly indestructible with a price/GB which is close to HDDs. And now we have LTO, which is even more dense in a similar form factor.
I've recovered data from tapes that were left outside in the rain, kicked around in storage boxes, and stained with smoke (after cleaning of course). All you need to do is keep magnets away (and by this I mean keeping the field strength under a few gauss... )
Any media relying on a chemical process to retain information is probably not a good idea... and I think it would cost more in the long run.
Almost every post here has been a take off BSD is dying.
But I can't blame them. While cafepress is nice to help the person selling money, the quality of the product is horrible. I'd rather give my money directly to the project than waste an extra $10 on a crappily screenprinted hat or mousepad.
The kernel is not implemented as true microkernel. There is seperation, but the message passing is limited to IO request packets that are sent to and from the HAL from (properly written) drivers. The drivers run in the same thread but in a different execution context / ring (IIRC through a "door"). But drivers that require "fast IO" are running in the same address space as the kernel. So while the IORP-using drivers shouldn't be able to take the system down, I wouldn't call it a microkernel exactly.
They've got the NSPR and Gecko, which are library-based implementations of a lot of the stuff under the hood that is shared. If someone were to sort of design a "network-transparent" XUL implementation; a thin front-end type thing mostly concerned with event handling... that sat on top and could communicate to a shared memory realm/daemon that hosted the common components that'd be kinda cool. The Unix implementation would probably be easier than the Windows one though.
I have used and mastered more than two dozen operating system families... Good for you. The point I'm trying to make here is that there is a tendancy to try and complexify a very simple problem... Mouse handlers are not a good example. Handling multiple buttons is easy. Polling the mouse for smooth interpretation of movement and acceleration is hard.
Okay, you're right. 5 cycles is hyperbole. But the difference is neglible in any system manufactured in the last 10 years. Even PDAs. This is considering that it is physically impossible to change mouse button state with a human finger more than 30 times a second, which is a reasonable hardware interrupt rate. (d + x + s) * 30, where d is the processing time for a single mouse button event, and s is the time to go from user mode into an interrupt context and back, and x is my additional time to add an OR and SHIFT... I'd say s probably dominates x, don't you?
And sure keyboards, joysticks, et. al. are all handled on different interrupts. Unless they're all USB devices (which is increasingly common, especially on Macs) in which case they all share an interrupt. And this interrupt does nothing except notify the input subsystem that it might need to copy something into memory... when it gets a chance. Well, a keyboard interrupt on an x86 PC will also include copying the scancode into a kernel buffer before it disappears, but I digress.
Similarly, the application code could have a switch statement, or not. So what, we might mis-predict a branch if it could handle multiple buttons? How often do you get mouse input events anyway? They're pretty sparse, when CPU speeds exceed 1GHz. I doubt that's a consideration either.
No... I think your strongest point might be the "extra debugging" an application developer would have to go through to handle multiple mouse buttons.
Of course, if it were me, I'd just NOT BIND anything to the mouse buttons I didn't feel like considering, or write my event handlers in such a way that keyboard+mouse strokes and alternate mouse button strokes invoke the same functions.
Or maybe I'll go NUTS and parse a configuration file. You know, like most video games out there or Mozilla or something. Surely there's some example code to help my poor helpless self out.
God... you just don't LIKE multiple mouse buttons, do you? What if we go back to calling them "Red", "Yellow", and "Blue" click. You can color the buttons with a magic marker if it's confusing.
It's kind of annoying that Sun decides that nearly EVERYTHING should be done through ifconfig. It's got about 4 different invocation types depending on what you're trying to do...
First you gotta plumb the interface. Then you might enable DHCP or BOOTP with it. Then you might use it to configure trunking or fail-over.
GAAAH.
Linux did one thing right with networking. Different commands that control different interfaces. iwconfig handles wireless auth and behavior. ifconfig handles address binding and state. dhclient handles DHCP control. some other kernel tools control trunking and packet shaping. etc.
Every mouse protocol (PS/2, serial, USB) are all packet based and treat mouse buttons as a parameter in the event. The OS drivers will reflect this.
The distinction between an OS which is designed from, as you call it, "the ground up" to support one mouse button vs. many can be summed up like this:
A parameter in an input event packet is ignored. This would be the same field that would indicated which joystick button was pressed or which keyboard key was used if the event class field was not of type 'MOUSE'. In fact the same field is probably co-opted with a mouse-motion event as the X-coordinate of the relative displacement (another field would be Y, and a third, Z, for the scroll wheel).
So essentially, if in your event handling code, you check to see if this is a mouse event, you might skip a switch statement that would respond to combination of mouse button chords you are interested in.
Wow. A whole 5 cycles, maybe. With absolutely zero change in the API. Congratulations.
Here's a hint, the button status is stored as a single word, with a bit for every button (this allows 32). The code for dealing with button change events over the USB HID interface doesn't care which button changed status: same code path for each. The end user applications can ignore every other mouse event except those concerning button0... I don't see what the problem is.
Sometimes you want to simultaneously have access to a left and right mouse click. Other times, ctrl click means something completely different.
In my case, when web-browsing, left click is follow in current frame, right click is a context menu, middle (or left+right click) is open in new window, and CTRL+left click is open in new tab.
I've been using this browsing method for years now. If I have to sit down at an OSX box, I have to make sure I bring a scroll mouse with me or I go completely nuts...
1) Only allow querying at intervals (say 1 second). This makes scanning prohibative. 2) Use (any) kind of challenge/response scheme. Car issues a random 30-bit number, key hashes this with an internal secret and replies, car validates. Syncronizing the 32-bit secret with a new key could be dead simple... something as dumb as maybe dip switches in the glove compartment.
I don't know... I'm not an embedded systems engineer but this is really simple stuff.
It was always easier to have a theater's screen be 1.85 or thereabouts to balance the width of the theater and how high you had to tilt your head back to see. You want to try to get as many people in the room at once without making them crane their necks to see.
The 4:3 aspect ratio is still used in filming since the lenses are spherical and wider aspect ratios are difficult to keep in focus while simultaneously avoiding distortion. Plus nowadays all the equipment (monitors, editing stations, etc.) use 4:3 screens. Of course, there's always anamorphic lenses, but that's a more recent development, and not everyone uses them.
Some companies' corporate agreements allow for home use as well. And furthermore some people take their equipment home. There's no reasonable way they could keep track of the distribution of a corporate key like that unless they audited each and every person who they could prove used it.
They have always put out their product on linux, it usually worked more consistently than a flash plugin, and IIRC it was always declawed (because they knew how picky we are about that sort of thing, and that'd we'd notice).
Not that I used it all that much what with mplayer and all, but it was nice to think they weren't complete jerks.
Blame the company CPMI or whatever it was called for the name. It was probably never going to marketed to end-users anyway. At least they didn't go changing it three times like firebird/phoenix/monkeyshit/firefox.
And OGG is a nice 3-letter extension that stands out from the rest of the crowded extension namespace. AAC is another good one (but that's too close to AC3 for my comfort, and it's confusing when you also see it as M4A)
... that many MP3 players (including the iPod) have dedicated MPEG audio frame-decoding hardware. They can't easily decode MP3s in software either. There have been single chip solutions for MP3 decoding since like before the year 2000. Vorbis decoding will be more difficult to implement on a chip, and the standard was only finalized recently, so a) no lead-time for chipmakers to develop the hardware b) not enough market to justify the R&D. This is why you don't see it in many portables (and then in only the most powerful ones CPU-wise).
I'm quite happy with my iRiver H-series player. And what good is an Audiotron if you can't upgrade it to play new formats anyway? If I can't hack it to play module files natively, it ain't worth the money.
Slashdot Mirror
are you saying you don't stream your logs across the network/frame relay to another site where they are permanently stored and monitored by unrelated personnel? If you have seperate admin teams, make them in charge of other people's logs (and vice-versa). It's like a checks and balances system.
Honestly... just re-copying a digital linear tape every 10 years is a safer bet than any other technology or solution.
DLT tapes are nearly indestructible with a price/GB which is close to HDDs. And now we have LTO, which is even more dense in a similar form factor.
I've recovered data from tapes that were left outside in the rain, kicked around in storage boxes, and stained with smoke (after cleaning of course). All you need to do is keep magnets away (and by this I mean keeping the field strength under a few gauss... )
Any media relying on a chemical process to retain information is probably not a good idea... and I think it would cost more in the long run.
nt
Almost every post here has been a take off BSD is dying.
But I can't blame them. While cafepress is nice to help the person selling money, the quality of the product is horrible. I'd rather give my money directly to the project than waste an extra $10 on a crappily screenprinted hat or mousepad.
Just skip it. Cafepress sucks.
The kernel is not implemented as true microkernel. There is seperation, but the message passing is limited to IO request packets that are sent to and from the HAL from (properly written) drivers. The drivers run in the same thread but in a different execution context / ring (IIRC through a "door").
But drivers that require "fast IO" are running in the same address space as the kernel.
So while the IORP-using drivers shouldn't be able to take the system down, I wouldn't call it a microkernel exactly.
They've got the NSPR and Gecko, which are library-based implementations of a lot of the stuff under the hood that is shared. If someone were to sort of design a "network-transparent" XUL implementation; a thin front-end type thing mostly concerned with event handling... that sat on top and could communicate to a shared memory realm/daemon that hosted the common components that'd be kinda cool. The Unix implementation would probably be easier than the Windows one though.
The single button mouse on a Mac is always treated as the "left" mouse button on more endowed mice.
For a fixed speaker installation, soldered contacts is your best bet.
I have used and mastered more than two dozen operating system families...
Good for you.
The point I'm trying to make here is that there is a tendancy to try and complexify a very simple problem...
Mouse handlers are not a good example. Handling multiple buttons is easy. Polling the mouse for smooth interpretation of movement and acceleration is hard.
Okay, you're right. 5 cycles is hyperbole. But the difference is neglible in any system manufactured in the last 10 years. Even PDAs. This is considering that it is physically impossible to change mouse button state with a human finger more than 30 times a second, which is a reasonable hardware interrupt rate. (d + x + s) * 30, where d is the processing time for a single mouse button event, and s is the time to go from user mode into an interrupt context and back, and x is my additional time to add an OR and SHIFT... I'd say s probably dominates x, don't you?
And sure keyboards, joysticks, et. al. are all handled on different interrupts. Unless they're all USB devices (which is increasingly common, especially on Macs) in which case they all share an interrupt.
And this interrupt does nothing except notify the input subsystem that it might need to copy something into memory... when it gets a chance.
Well, a keyboard interrupt on an x86 PC will also include copying the scancode into a kernel buffer before it disappears, but I digress.
Similarly, the application code could have a switch statement, or not. So what, we might mis-predict a branch if it could handle multiple buttons? How often do you get mouse input events anyway? They're pretty sparse, when CPU speeds exceed 1GHz. I doubt that's a consideration either.
No... I think your strongest point might be the "extra debugging" an application developer would have to go through to handle multiple mouse buttons.
Of course, if it were me, I'd just NOT BIND anything to the mouse buttons I didn't feel like considering, or write my event handlers in such a way that keyboard+mouse strokes and alternate mouse button strokes invoke the same functions.
Or maybe I'll go NUTS and parse a configuration file. You know, like most video games out there or Mozilla or something. Surely there's some example code to help my poor helpless self out.
God... you just don't LIKE multiple mouse buttons, do you? What if we go back to calling them "Red", "Yellow", and "Blue" click. You can color the buttons with a magic marker if it's confusing.
I didn't know it was restrictive to Apple... I thought it was like the Moz or Apache license.
It's kind of annoying that Sun decides that nearly EVERYTHING should be done through ifconfig. It's got about 4 different invocation types depending on what you're trying to do...
First you gotta plumb the interface. Then you might enable DHCP or BOOTP with it. Then you might use it to configure trunking or fail-over.
GAAAH.
Linux did one thing right with networking. Different commands that control different interfaces.
iwconfig handles wireless auth and behavior.
ifconfig handles address binding and state.
dhclient handles DHCP control.
some other kernel tools control trunking and packet shaping. etc.
Instead of one hideously long man page. (Shudder)
None.
I was talking about Moz/Firefox. Which happens to work the same on all platforms once you configure it.
I don't primarily use a Mac, get it?
Every mouse protocol (PS/2, serial, USB) are all packet based and treat mouse buttons as a parameter in the event. The OS drivers will reflect this.
The distinction between an OS which is designed from, as you call it, "the ground up" to support one mouse button vs. many can be summed up like this:
A parameter in an input event packet is ignored. This would be the same field that would indicated which joystick button was pressed or which keyboard key was used if the event class field was not of type 'MOUSE'. In fact the same field is probably co-opted with a mouse-motion event as the X-coordinate of the relative displacement (another field would be Y, and a third, Z, for the scroll wheel).
So essentially, if in your event handling code, you check to see if this is a mouse event, you might skip a switch statement that would respond to combination of mouse button chords you are interested in.
Wow. A whole 5 cycles, maybe. With absolutely zero change in the API. Congratulations.
Here's a hint, the button status is stored as a single word, with a bit for every button (this allows 32). The code for dealing with button change events over the USB HID interface doesn't care which button changed status: same code path for each.
The end user applications can ignore every other mouse event except those concerning button0... I don't see what the problem is.
You'd think Apple would get the hint and be providing this out of the box. Hell my Palm m100 had a more configurable from the get go.
Sometimes you want to simultaneously have access to a left and right mouse click. Other times, ctrl click means something completely different.
In my case, when web-browsing, left click is follow in current frame, right click is a context menu, middle (or left+right click) is open in new window, and CTRL+left click is open in new tab.
I've been using this browsing method for years now. If I have to sit down at an OSX box, I have to make sure I bring a scroll mouse with me or I go completely nuts...
Time to bitch about the slashdot readership again... oh man that line about Taco and the iPod never gets old.
And get this, Al Gore didn't actually invent the Internet. Hahahah!
*wipes tear away from eye*
1) Only allow querying at intervals (say 1 second). This makes scanning prohibative.
2) Use (any) kind of challenge/response scheme. Car issues a random 30-bit number, key hashes this with an internal secret and replies, car validates. Syncronizing the 32-bit secret with a new key could be dead simple... something as dumb as maybe dip switches in the glove compartment.
I don't know... I'm not an embedded systems engineer but this is really simple stuff.
I want AES encryption protecting my car...
It was always easier to have a theater's screen be 1.85 or thereabouts to balance the width of the theater and how high you had to tilt your head back to see. You want to try to get as many people in the room at once without making them crane their necks to see.
The 4:3 aspect ratio is still used in filming since the lenses are spherical and wider aspect ratios are difficult to keep in focus while simultaneously avoiding distortion. Plus nowadays all the equipment (monitors, editing stations, etc.) use 4:3 screens. Of course, there's always anamorphic lenses, but that's a more recent development, and not everyone uses them.
Some companies' corporate agreements allow for home use as well. And furthermore some people take their equipment home. There's no reasonable way they could keep track of the distribution of a corporate key like that unless they audited each and every person who they could prove used it.
They have always put out their product on linux, it usually worked more consistently than a flash plugin, and IIRC it was always declawed (because they knew how picky we are about that sort of thing, and that'd we'd notice).
Not that I used it all that much what with mplayer and all, but it was nice to think they weren't complete jerks.
Blame the company CPMI or whatever it was called for the name. It was probably never going to marketed to end-users anyway. At least they didn't go changing it three times like firebird/phoenix/monkeyshit/firefox.
And OGG is a nice 3-letter extension that stands out from the rest of the crowded extension namespace. AAC is another good one (but that's too close to AC3 for my comfort, and it's confusing when you also see it as M4A)
... that many MP3 players (including the iPod) have dedicated MPEG audio frame-decoding hardware. They can't easily decode MP3s in software either. There have been single chip solutions for MP3 decoding since like before the year 2000. Vorbis decoding will be more difficult to implement on a chip, and the standard was only finalized recently, so a) no lead-time for chipmakers to develop the hardware b) not enough market to justify the R&D. This is why you don't see it in many portables (and then in only the most powerful ones CPU-wise).
I'm quite happy with my iRiver H-series player. And what good is an Audiotron if you can't upgrade it to play new formats anyway? If I can't hack it to play module files natively, it ain't worth the money.