Hard links don't help in general with the unix security model since they share an inode (where the owner, group, and mode is located). Extra hard links are just extra directory entries. The one exception is when the location of a file is stored in two seperate folders with different traverse settings (execute on directories) which can control access by ability-to-name.
But that's an all or nothing method, and you can't hardlink subdirectories so you end up linking files individually, which is a bad approach unless automated as part of a file management system.
SELinux _is_ a good solution, provided that developers or third parties care enough to develop robust profiles for applications, with nods to different roles a user might take on in day to day usage of that software, and tailoring access needs to that. Fedora is thankfully going down this path, and establishing some best practices.
In SELinux, who can do what is determined largely by (multiple, simultaneous) user roles, application roles, and allowed transitions between them. Application roles that act on behalf of users are how requested capabilities on objects are granted. You grant an application role (called context) the ability to do operations on types of objects. Thus you tag files with object types (which is only important for file activity; other important types of permissions for operations on non-file objects can be delineated).
I think what's holding that back is that Administrators suffer from the lack of good tools to manipulate the various security descriptors for objects and to do what-if analysis.
It makes the original stream much larger, and peeled copies don't sound as good as the "real thing" encoded directly at the bitrate.
It's only useful if for some reason you have a broadcast system where you have a live source and need to trunk into multiple bitrate at some processing stage.
The situation is unlikely... most people would rather just run seperate streams since computing power is plentiful now.
First off, AAC2 is not what you need. That's got goodies for channel seperatation that makes more sense for home theatre-type apps IIRC.
The benefit to Vorbis is that you've got the perceptual noise shaping thing going on (the other one that does that is Musepack), which AAC+ isn't using. Which means it has a shitty sounding failure mode when you shave those bps too closely. And the high-frequency re-synthesis, while a nice feature for bandlimited scenarios and things like ring-tones, isn't exactly a way to get a high-fidelity representation.
Your listening environment is going to have a lot to do with it. If the environment is already noisy, then AAC+ is going to be a good choice since it degrades high frequencies in a non-obvious way.
Otherwise, suck up a little extra space on the card and go with vorbis.
Also, between Vorbis and AAC+, Vorbis is more likely to have a playback app for your phone (AAC+ is a bit new for that yet)
You need a userland "personality" per VM that does the work that the VM'd thread is not allowed to do (simulate hardware).
Userland VMs like VMWare, DosEMU and QEMU would be modified to work with KVM to leverage a common infrastructure.
Currently VMWare and QEMU have special add-ons that need to be loaded into the kernel to speed things up; this KVM would create a common platform for that and source-level API. Which is nice...
IT (especially when connected to R&D or rapidly changing environments) can be as dynamic or encompass disciplines one would normally associate with engineering.
Java is well-suited for large projects with fairly well defined requirements (and potentially complex interactions between objects/components).
If the requirements are ill defined, or the system small enough to likely be confined to a single box, or the object model relatively simple (few types, lots of instances) then perl is the first thing I think of...
Unless the object model is regular and layered, then I think ruby. Unless there is a need for blistering IO and syscalltastic goodness with function overloading, then C++ Unless there isn't a need for too many object tricks or the STL, then C.
All of the above languages have excellent tools, environments, and libraries. I think they've all got it made in the shade.
BTW, the easiest language to develop and troubleshoot is JavaScript (ecmascript). Tools like firebug make it stupid-easy. Of course, there's no regularized non-web environment for it; I've seen small efforts to that end but they always end up not going far. It's a real shame, IMHO. Prototyping, lazy-evaluating, duck typing, easy-to-read language... what's not to love?
I don't know how much current you can source with such a design... I suppose with some power MOSFETs in parallel and some big-ass filtering caps you could get the desired effect.
Loratadine You can buy it in 1000-count bottles at 10mg each at Costco. Also, if you need something stronger, combine it with pseudophedrine (sudafed), or look for a fexofenadine generic.
Why couldn't they just release an NT 5.3 that's backwards compatible with the drivers from XP/2003 to some degree (WDM), while ditching the older VXD model?
What would have been wrong with that? And keep the fixes for how async IO is done, and keep the new schedulers, and keep the new installer process, and so on.
I don't care if it was a $149 box and $79 upgrade like XP vs. 2000... I just want some continuity between my OSs. Give me some nice benefits without the drawbacks.
I mean, you want to talk about being business-oriented; it didn't take a kernel version jump to give us the features we wanted (we being the IT folks). DX10? New APIs to validate our apps against? We don't want any of that stupid shit.
SQL Server 2005 runs just fine on Server 2003 fuck you very much microsoft.
Oh, I forgot. They need a secure DRM platform so they can make me rent my software and music. God fucking damn it.
Calling economists liars because the free market doesn't match your day-to-day economic experiences is like calling a paint manufacturer a liar because his black paint does not emit perfect black body radiation.
They tend to be full-fledged networked computers with a webserver and FTP server containing your TIFF/PDF files and stuff. No need for "OS support" there.
The TI-89 is useful for a whole bunch of other reasons: * Quick factoring of integers, radicals, polynomials * Term collection and simplification * Handling of arbitrarily large values without loss of precision (esp w.r.t. factorials) * Substitution of variables or expressions in general formulas (user-provided function)
It really can't "solve" very much other than 4th degree polynomial roots. It's really just there to help you manipulate a complex expression without making a mistake (but you really need to be doing the manipulations... which of course requires a bit of knowledge, don't it?)
BTW I distinctly remember adding the incomplete beta and gamma functions to my TI-89, and I think error function too. They would simplify to trivial expressions if they could (to promote further manipulation) or returned numerical solutions if so coerced. I thought it was pretty slick...
iRiver flash portables are godly. They have like 50 different varieties with combinations of flash size, battery life (LiO vs. AAAs), water resistance, radio, whatever. And they almost all come with a armband strap attachment point for the gym.
It's too bad they stopped making the older HD portables (the H10s and later suck).
Like a plugin that checks the netblock of the result of a DNS lookup on a URL... if it's in a range of known parking sites or phising sites, it'd throw up an appropriate error/blocked page.
..with hyperthreading. Switch context when you get a stall, keep going. Of course HT processors didn't have dedicated execution units for each context, and a quirk of the P4 architecture would keep that stalled thread occupying those shared units, preventing the "current" thread from proceeding. End result: people turned it off because it sometimes hurt multi-threaded performance. It was a mistake to introduce it in a half-assed implementation.
Intel wisely abandoned it and dedicated more chip area to cache, prefetch, and the like. A re-visit of that technology with more duplicated execution paths might be wise on a dual core server chip... quad core on a lower power budget.
1) ALOMs on SPARC use a service processor also... so that shouldn't be a big surprise. 2) Set your LOM to defer to BIOS, and your BIOS for serial port emulation, with an OS-mitigated handover (if that config option is there). Then set up your OSs to boot with a serial console. Attach all serial ports to a Cyclades or other terminal server. Enjoy the deliciousness. 3) Buy SATA in pairs and use (software!) RAID 1. It's cheap, fast and easy. 4) Consider using something BESIDES Solaris on x86. Maybe linux or freebsd? Especially on small n-way platforms where you don't need 32+ processors or zones...
Slashdot Mirror
Hard links don't help in general with the unix security model since they share an inode (where the owner, group, and mode is located). Extra hard links are just extra directory entries.
The one exception is when the location of a file is stored in two seperate folders with different traverse settings (execute on directories) which can control access by ability-to-name.
But that's an all or nothing method, and you can't hardlink subdirectories so you end up linking files individually, which is a bad approach unless automated as part of a file management system.
SELinux _is_ a good solution, provided that developers or third parties care enough to develop robust profiles for applications, with nods to different roles a user might take on in day to day usage of that software, and tailoring access needs to that. Fedora is thankfully going down this path, and establishing some best practices.
In SELinux, who can do what is determined largely by (multiple, simultaneous) user roles, application roles, and allowed transitions between them. Application roles that act on behalf of users are how requested capabilities on objects are granted. You grant an application role (called context) the ability to do operations on types of objects. Thus you tag files with object types (which is only important for file activity; other important types of permissions for operations on non-file objects can be delineated).
I think what's holding that back is that Administrators suffer from the lack of good tools to manipulate the various security descriptors for objects and to do what-if analysis.
It makes the original stream much larger, and peeled copies don't sound as good as the "real thing" encoded directly at the bitrate.
It's only useful if for some reason you have a broadcast system where you have a live source and need to trunk into multiple bitrate at some processing stage.
The situation is unlikely... most people would rather just run seperate streams since computing power is plentiful now.
First off, AAC2 is not what you need. That's got goodies for channel seperatation that makes more sense for home theatre-type apps IIRC.
The benefit to Vorbis is that you've got the perceptual noise shaping thing going on (the other one that does that is Musepack), which AAC+ isn't using. Which means it has a shitty sounding failure mode when you shave those bps too closely. And the high-frequency re-synthesis, while a nice feature for bandlimited scenarios and things like ring-tones, isn't exactly a way to get a high-fidelity representation.
Your listening environment is going to have a lot to do with it. If the environment is already noisy, then AAC+ is going to be a good choice since it degrades high frequencies in a non-obvious way.
Otherwise, suck up a little extra space on the card and go with vorbis.
Also, between Vorbis and AAC+, Vorbis is more likely to have a playback app for your phone (AAC+ is a bit new for that yet)
Ogg needs to be simpler name-wise. Right. And MP3 inspired the idea of "Compressed Music on My Computer" the first time you heard about it on IRC.
Give me a fucking break.
Advocacy and industry exposure is the only way to turn Vorbis from "zuh" into the next "google".
You need a userland "personality" per VM that does the work that the VM'd thread is not allowed to do (simulate hardware).
Userland VMs like VMWare, DosEMU and QEMU would be modified to work with KVM to leverage a common infrastructure.
Currently VMWare and QEMU have special add-ons that need to be loaded into the kernel to speed things up; this KVM would create a common platform for that and source-level API. Which is nice...
That's what the uncatchable STOP signal is for.
AC, meet System V unix. Unix, meet clueless AC.
A perfect spiral thrown from the laser rocket arm of Patton Manning hits an unsuspecting A.C. right in his un-jock-cup'd gonads.
Stick that in your pipe and smoke it.
...well, some of us are here by choice.
IT (especially when connected to R&D or rapidly changing environments) can be as dynamic or encompass disciplines one would normally associate with engineering.
Don't lump us all in together, man.
Java is well-suited for large projects with fairly well defined requirements (and potentially complex interactions between objects/components).
If the requirements are ill defined, or the system small enough to likely be confined to a single box, or the object model relatively simple (few types, lots of instances) then perl is the first thing I think of...
Unless the object model is regular and layered, then I think ruby.
Unless there is a need for blistering IO and syscalltastic goodness with function overloading, then C++
Unless there isn't a need for too many object tricks or the STL, then C.
All of the above languages have excellent tools, environments, and libraries. I think they've all got it made in the shade.
BTW, the easiest language to develop and troubleshoot is JavaScript (ecmascript). Tools like firebug make it stupid-easy. Of course, there's no regularized non-web environment for it; I've seen small efforts to that end but they always end up not going far. It's a real shame, IMHO. Prototyping, lazy-evaluating, duck typing, easy-to-read language... what's not to love?
I don't know *kicks dirt*
(last time I checked)
so what else is new.
I don't know how much current you can source with such a design... I suppose with some power MOSFETs in parallel and some big-ass filtering caps you could get the desired effect.
Loratadine
You can buy it in 1000-count bottles at 10mg each at Costco.
Also, if you need something stronger, combine it with pseudophedrine (sudafed), or look for a fexofenadine generic.
Why couldn't they just release an NT 5.3 that's backwards compatible with the drivers from XP/2003 to some degree (WDM), while ditching the older VXD model?
What would have been wrong with that? And keep the fixes for how async IO is done, and keep the new schedulers, and keep the new installer process, and so on.
I don't care if it was a $149 box and $79 upgrade like XP vs. 2000... I just want some continuity between my OSs. Give me some nice benefits without the drawbacks.
I mean, you want to talk about being business-oriented; it didn't take a kernel version jump to give us the features we wanted (we being the IT folks). DX10? New APIs to validate our apps against? We don't want any of that stupid shit.
SQL Server 2005 runs just fine on Server 2003 fuck you very much microsoft.
Oh, I forgot. They need a secure DRM platform so they can make me rent my software and music. God fucking damn it.
Real IEDs do not have flashing lights or a ticking clock on them, unlike the movies would have you believe.
How anyone could confuse these things for anything dangerous makes me wonder how incredibly stupid the people in charge of our security really are.
Calling economists liars because the free market doesn't match your day-to-day economic experiences is like calling a paint manufacturer a liar because his black paint does not emit perfect black body radiation.
:-)
Wow, I'm going to have to remember that one.
Or both!?! (string tremelo)
Not only is the word not japanese, Tira-mi-su is three italian words.
(It means "pick-me-up")
No one has to use ccTLDs at all, in any country. It's always been completely voluntary.
.us domains. It's new and trendy (ugh).
Also, there are plenty of
They tend to be full-fledged networked computers with a webserver and FTP server containing your TIFF/PDF files and stuff. No need for "OS support" there.
*does a jig with two thumbs up*
*stabs self in eyes with thumbs*
JAZZ HANDS!
The TI-89 is useful for a whole bunch of other reasons:
* Quick factoring of integers, radicals, polynomials
* Term collection and simplification
* Handling of arbitrarily large values without loss of precision (esp w.r.t. factorials)
* Substitution of variables or expressions in general formulas (user-provided function)
It really can't "solve" very much other than 4th degree polynomial roots. It's really just there to help you manipulate a complex expression without making a mistake (but you really need to be doing the manipulations... which of course requires a bit of knowledge, don't it?)
BTW I distinctly remember adding the incomplete beta and gamma functions to my TI-89, and I think error function too. They would simplify to trivial expressions if they could (to promote further manipulation) or returned numerical solutions if so coerced. I thought it was pretty slick...
iRiver flash portables are godly. They have like 50 different varieties with combinations of flash size, battery life (LiO vs. AAAs), water resistance, radio, whatever. And they almost all come with a armband strap attachment point for the gym.
It's too bad they stopped making the older HD portables (the H10s and later suck).
Like a plugin that checks the netblock of the result of a DNS lookup on a URL... if it's in a range of known parking sites or phising sites, it'd throw up an appropriate error/blocked page.
That'd be a neat extension to have.
..with hyperthreading. Switch context when you get a stall, keep going. Of course HT processors didn't have dedicated execution units for each context, and a quirk of the P4 architecture would keep that stalled thread occupying those shared units, preventing the "current" thread from proceeding. End result: people turned it off because it sometimes hurt multi-threaded performance. It was a mistake to introduce it in a half-assed implementation.
Intel wisely abandoned it and dedicated more chip area to cache, prefetch, and the like. A re-visit of that technology with more duplicated execution paths might be wise on a dual core server chip... quad core on a lower power budget.
1) ALOMs on SPARC use a service processor also... so that shouldn't be a big surprise.
2) Set your LOM to defer to BIOS, and your BIOS for serial port emulation, with an OS-mitigated handover (if that config option is there). Then set up your OSs to boot with a serial console. Attach all serial ports to a Cyclades or other terminal server. Enjoy the deliciousness.
3) Buy SATA in pairs and use (software!) RAID 1. It's cheap, fast and easy.
4) Consider using something BESIDES Solaris on x86. Maybe linux or freebsd? Especially on small n-way platforms where you don't need 32+ processors or zones...