because there's a ton of Doom, Quake, and DN3D ports and extensions due to the source being available. Those are free.
So by the virtue of them being free 3DRealms wouldn't in their right minds release DNF unless ita underpinnings at least as high quality as those engines. There's some leeway here... I'd probably buy it just for the art resources and the single player gameplay if it's original and reasonably entertaining.
In that objects and processes get security contexts and you can create transition and access rules between the contexts. You can build a whole bunch of different models on top of this if you have the right UI tools and idioms. RBC, capability models, whatever you want.
To some degree a capability model is made available in SELinux by packages bundling they're own rule sets that define "acceptable behavior" according to their best estimation of typical usage of such software. (Sure you _could_ use apache to serve up/etc/passwd to remote users, but why would you want to?)
If you have sufficient coverage with default deny, you could turn of the default UNIX access semantics in the kernel and rely completely on SELinux enforcement.
But that reality is still years off and requires support by anyone wanting to deploy serivces on that platform. (sigh) POSIX needs to define a standard in this area or something to get everyone on the same page and thinking about it.
Texture-mapping the 2D web onto the walls doesn't accomplish much.
That's the problem with ALL of the 3D web-browsing/user-interface implementations right now. You use markup and controls that are designed to render onto a flat 2D raster surface. It seems logical to bundle an existing renderer (an IE/gecko control, or a UI toolkit window rendering) and point it at a texture, and then schlep that into a 3D framework... but that's just so completely wrong.
At least for web browsing... if you want to make it 3D then you first need to WRITE a 3d renderer for XHTML. You need to figure out some way of interpreting the tags and markup and using 3d (or 3d accelerated algorithms) to do something intelligent with all that CSS and hints.
You are going to need to at least have an antialiased glyph renderer for text. Either using real polygons or dynamically created texture maps (maybe a single mip-mapped texture for each character). Because on the web the most important thing to be able to have is LEGIBLY RENDERED TEXT.
Maybe for the sake of keeping polycounts low you reserve the shape-defined text for h1/h2 tags and render the rest as rasters. But do something useful with them.
Don't start putting textures containing text at oblique angles unless you've got it at least 2x oversampled. Instead, render it to a surface in a bounding box and "float" it where you want but keep it's normal pointed straight at the view frustrum. Or use a particle or sprite primitive.
Come on people!
Have a look at some demoscene demostrations and how they integrate text and 3d. I guarantee you can always read the text clearly (as it is often used to convey jokes or greetz). And that stuff is just for fun.
Lots of us do this kind of thing at work. If the boss wants an Access/Excel frontend to an internal database keeping track of this and that, who are we to say no? It's fairly easy to do and you can leave the tricky stuff as DB procs in Postgres/Oracle, whatever. Write some simple VBA glue and bam, you've got a nice reporting/data entry tool tailored to your users' needs. Didn't have to pay for a single thing.
Take a simple linux install disk that uses initrd of your choice and comes with cryptoloop. Modify the initrd so it asks for a password before setting up the "real" root device on your harddrive. Burn the install CD with the modified initrd. Install linux using this disk (so it installs onto the now-encrypted hard drive) In order to use the system, you'll have to insert the install CD and use it as a boot CD everytime. But in this fashion no un-encrypted data is on any of your hard drives. To remove evidence that you can even access it, remove the CD when you're done using the computer, and store it in an inconspicous place.
If you prefer using windows, deal with linux to the point you can install QEMU or VMWare. Install Windows normally in the virtual environment and it is encrypted as well (including the swap file!).
I haven't had occaision to fiddle around with group membership with the GUI tools. Also, the times when I hit usrmgr heavily was when using the TDB backend, not the LDAP backend, and for some reason I had good luck with that. I think the locking and round-trip complexity of the TDB is simpler so Samba is less likely to screw up when using non-native tools.
I think the web front end you're speaking of is LAM. Looks pretty cool. Also check out "gosa".
If you want Samba (and NFS and LDAP and Kerberos/AD) to work correctly, use RHEL/CentOS/Fedora. SuSE patches their supported Samba something fierce... I don't know why.
I've got stock RHEL 4/the latest SRPM of samba hosting shares and an NT4 domain and it stays up until I shut down the machine. Nothing too exciting about it.
And if you want to confuse lowly developers just omit that in a module and start throwing around implicit function compositions too: sub fix_bad_words {
shift;
my $BADWORDREGEX = shift || "(fuck|shit|cunt)";
join map split $IFS, {/$BADWORDREGEX/ ? "*bleep*" : $_;}, $,; }
Train the autopilot so well that it can handle any "situation" a typical 20+ year commercial veteran has seen. (It's less an "AI/sentinence" issue but more collecting and processing data offline). If the computer couldn't handle it, most pilots would know what to do either. And you can always add a failsafe like: give control to human staff on board, or emergency remote flight control (some FAA building somewhere), or power down engines 80% and attempt to minimize kinetic energy impact to ground... or something.
Instrument planes that are still human-flown with an order of magnitude more sensors than they currently have. Have backups for them (pressure, GPS, and dead-reckoning altitimeters, etc.) Record tons of flight data. Then what you do is add prototypical "auto-pilot" systems that are supposed to deal with imperfect inputs. Have the auto-pilot make decisions during the flight plan that don't actually translate into flight manuvers. Then you can analyze it on the ground to see how the real flight and the simulated flight match up... see what new kinds of logic and detection and resolution algorithms need to be added to the programming. Rinse, repeat. Eventually you should have an autopilot that makes all the "right" decisions even when weird stuff happens in the air, and you can verify that after the fact.
Then you let the autopilot fly, with human pilots for failsafe. Try that for a few years.
Eventually once you get enough flight hours you should feel reasonably confident the auto-pilot system has enough internal redundancy and "experience" that it bests most actual pilots. Its a time consuming, iterative process. But it can have enormous potential.
NetApp is a different animal. They have some kind of uber-database FS so I would expect their disks to be self-identifying and pluggable... this concept extends to volumes and clusters in their high end equipment. I'm pretty confident the non-Windows based NAS products from Dell are just as hardy. But Promise, HighPoint, LSI, Adaptec, etc. and the others could care less. They'll setup something that works on your disks and store some configuration on the drives, and the rest in NVRAM, but good luck moving them to another machine (LSI is better at this than most).
Windows is kinda picky about software RAID. It's not that it can't grok the volumes, it just doesn't want to bring up volumes that have unfamiliar UUIDs or system IDs. Which is kinda a shame but there are tools to get around this. I don't recommend it for unattended use (but for interactive use it's probably worth it).
Linux, FreeBSD, and Solaris aren't so picky. They'll bring up a volume set if it looks like "it's all there". Which is the best. Because you can just unplug a bunch of drive sleds from one enclosure and shove them into another (without regarding order even) and be reasonably assured that your data will still be there.
Don't run cron jobs on NAS. Bad, bad!!! You don't need to run slocate on a system you never use for interactive processing.;) Hell, don't run anything not directly related to moving data in and out of the system. Demand-based load is easy to model and there's less chance it'll fail unexpectedly (like when you're on vacation or something).
Software RAID is documented. If it fails, you can plug the drives into another system that understands the RAID format and get at the data. Hardware RAID is often propietary and all-or-nothing. You're not going to get much help on recovering your data from Promise or Adaptec when one of your cards go south. They'll say: "But didn't you keep recent backups???" (which is The Truth (tm) but still...)
Seriously, ATI cards suck to support. I don't recommend them to anybody no matter what OS they use. Unless we're talking about like a R200-based platform (R8500, 9100, 9000Pro, 9200) which is pretty well understood and should be support by Windows HCL and Linux OSS drivers completely (incl. Xinerama/tv-out)
Anything newer than that is a crapshoot.
And you can tell ATI feels this way too. You know the FireMV line... their uber-stable flagship line of workstation multi-monitor visualization cards? All R200-based chips. They managed to shove 4 onto a board with a single passive heatsink and tons of texture memory. They leave the R300 and R400 cards for the Quadro line (w/certain features disabled) and the enthusiast boards (where crashes are expected anyway).
Excel is for the VISUAL EDITING of a limited set of datapoints with manageable dimensonality. You aren't supposed to try to load your whole dataset at once into it, only a representative subset. Why would you use an application that tries to load every single datapoint into memory at once just so you can run batch processing type functions that operate on subsets at the data at a time? It's not like you are going to tweak any individual cell. It just seems ass-backwards.
No, there are plenty of better tools. For example, Programmer's Notepad or Texpad, which will allow you to visually examine the head -1 to see the exact column layout and make a good guess as to the seperator between fields of various types. If your error is in the middle, (detected by WHICH program, I might add? How would you scan that many lines in Excel visually to find that problem anyway?) you could just use a sed statement with a line notation (or an expression that MATCHES the kinds of errors you're having) to elide the ill-constructed line.
If you can't reasonably expect to spot the problem by visually scanning in Excel over the cells because you've got datasets that large, then you shouldn't be using a visual tool anyway.
... can't work their way around a copy of R or Scilab (free), then I think they should be fired. That's like a administrative assistant who can't speak english but can sign ASL really well. *eye roll*
It's called head. And tail. Head and then open in Excel. Why would you try to open the whole thing at once? Use tail to get an idea of the range of record IDs or whatever.
What are you, a fucking imbecile? It's called awk and grep. Jesus fucking christ. If you deal with log files on a daily basis then you better learn to use some decent text processing tools.
If you're doing any kind of engineering analysis in Excel, you need to learn some new tools. It's called Matlab. If that's out of your reach, there's Scilab. Anything but Excel. Christ. That's like repairing a computer with a fisher price mallet.
Slashdot Mirror
because there's a ton of Doom, Quake, and DN3D ports and extensions due to the source being available. Those are free.
So by the virtue of them being free 3DRealms wouldn't in their right minds release DNF unless ita underpinnings at least as high quality as those engines. There's some leeway here... I'd probably buy it just for the art resources and the single player gameplay if it's original and reasonably entertaining.
In that objects and processes get security contexts and you can create transition and access rules between the contexts.
/etc/passwd to remote users, but why would you want to?)
You can build a whole bunch of different models on top of this if you have the right UI tools and idioms. RBC, capability models, whatever you want.
To some degree a capability model is made available in SELinux by packages bundling they're own rule sets that define "acceptable behavior" according to their best estimation of typical usage of such software. (Sure you _could_ use apache to serve up
If you have sufficient coverage with default deny, you could turn of the default UNIX access semantics in the kernel and rely completely on SELinux enforcement.
But that reality is still years off and requires support by anyone wanting to deploy serivces on that platform.
(sigh)
POSIX needs to define a standard in this area or something to get everyone on the same page and thinking about it.
Texture-mapping the 2D web onto the walls doesn't accomplish much.
That's the problem with ALL of the 3D web-browsing/user-interface implementations right now. You use markup and controls that are designed to render onto a flat 2D raster surface. It seems logical to bundle an existing renderer (an IE/gecko control, or a UI toolkit window rendering) and point it at a texture, and then schlep that into a 3D framework... but that's just so completely wrong.
At least for web browsing... if you want to make it 3D then you first need to WRITE a 3d renderer for XHTML. You need to figure out some way of interpreting the tags and markup and using 3d (or 3d accelerated algorithms) to do something intelligent with all that CSS and hints.
You are going to need to at least have an antialiased glyph renderer for text. Either using real polygons or dynamically created texture maps (maybe a single mip-mapped texture for each character).
Because on the web the most important thing to be able to have is LEGIBLY RENDERED TEXT.
Maybe for the sake of keeping polycounts low you reserve the shape-defined text for h1/h2 tags and render the rest as rasters. But do something useful with them.
Don't start putting textures containing text at oblique angles unless you've got it at least 2x oversampled. Instead, render it to a surface in a bounding box and "float" it where you want but keep it's normal pointed straight at the view frustrum. Or use a particle or sprite primitive.
Come on people!
Have a look at some demoscene demostrations and how they integrate text and 3d. I guarantee you can always read the text clearly (as it is often used to convey jokes or greetz). And that stuff is just for fun.
Lots of us do this kind of thing at work.
If the boss wants an Access/Excel frontend to an internal database keeping track of this and that, who are we to say no?
It's fairly easy to do and you can leave the tricky stuff as DB procs in Postgres/Oracle, whatever. Write some simple VBA glue and bam, you've got a nice reporting/data entry tool tailored to your users' needs. Didn't have to pay for a single thing.
Take a simple linux install disk that uses initrd of your choice and comes with cryptoloop.
Modify the initrd so it asks for a password before setting up the "real" root device on your harddrive.
Burn the install CD with the modified initrd. Install linux using this disk (so it installs onto the now-encrypted hard drive)
In order to use the system, you'll have to insert the install CD and use it as a boot CD everytime. But in this fashion no un-encrypted data is on any of your hard drives. To remove evidence that you can even access it, remove the CD when you're done using the computer, and store it in an inconspicous place.
If you prefer using windows, deal with linux to the point you can install QEMU or VMWare. Install Windows normally in the virtual environment and it is encrypted as well (including the swap file!).
I haven't had occaision to fiddle around with group membership with the GUI tools. Also, the times when I hit usrmgr heavily was when using the TDB backend, not the LDAP backend, and for some reason I had good luck with that. I think the locking and round-trip complexity of the TDB is simpler so Samba is less likely to screw up when using non-native tools.
I think the web front end you're speaking of is LAM. Looks pretty cool. Also check out "gosa".
usrmgr.exe?
Or dsa.msc?
If you want Samba (and NFS and LDAP and Kerberos/AD) to work correctly, use RHEL/CentOS/Fedora.
/the latest SRPM of samba hosting shares and an NT4 domain and it stays up until I shut down the machine. Nothing too exciting about it.
SuSE patches their supported Samba something fierce... I don't know why.
I've got stock RHEL 4
And if you want to confuse lowly developers just omit that in a module and start throwing around implicit function compositions too:
sub fix_bad_words {
shift;
my $BADWORDREGEX = shift || "(fuck|shit|cunt)";
join map split $IFS, {/$BADWORDREGEX/ ? "*bleep*" : $_;}, $,;
}
Bonus points: So what does it do?
Train the autopilot so well that it can handle any "situation" a typical 20+ year commercial veteran has seen. (It's less an "AI/sentinence" issue but more collecting and processing data offline). If the computer couldn't handle it, most pilots would know what to do either. And you can always add a failsafe like: give control to human staff on board, or emergency remote flight control (some FAA building somewhere), or power down engines 80% and attempt to minimize kinetic energy impact to ground... or something.
The progression to this as follows:
Instrument planes that are still human-flown with an order of magnitude more sensors than they currently have. Have backups for them (pressure, GPS, and dead-reckoning altitimeters, etc.) Record tons of flight data. Then what you do is add prototypical "auto-pilot" systems that are supposed to deal with imperfect inputs. Have the auto-pilot make decisions during the flight plan that don't actually translate into flight manuvers. Then you can analyze it on the ground to see how the real flight and the simulated flight match up... see what new kinds of logic and detection and resolution algorithms need to be added to the programming. Rinse, repeat. Eventually you should have an autopilot that makes all the "right" decisions even when weird stuff happens in the air, and you can verify that after the fact.
Then you let the autopilot fly, with human pilots for failsafe. Try that for a few years.
Eventually once you get enough flight hours you should feel reasonably confident the auto-pilot system has enough internal redundancy and "experience" that it bests most actual pilots. Its a time consuming, iterative process. But it can have enormous potential.
NetApp is a different animal. They have some kind of uber-database FS so I would expect their disks to be self-identifying and pluggable... this concept extends to volumes and clusters in their high end equipment. I'm pretty confident the non-Windows based NAS products from Dell are just as hardy.
But Promise, HighPoint, LSI, Adaptec, etc. and the others could care less. They'll setup something that works on your disks and store some configuration on the drives, and the rest in NVRAM, but good luck moving them to another machine (LSI is better at this than most).
Windows is kinda picky about software RAID. It's not that it can't grok the volumes, it just doesn't want to bring up volumes that have unfamiliar UUIDs or system IDs. Which is kinda a shame but there are tools to get around this. I don't recommend it for unattended use (but for interactive use it's probably worth it).
Linux, FreeBSD, and Solaris aren't so picky. They'll bring up a volume set if it looks like "it's all there". Which is the best. Because you can just unplug a bunch of drive sleds from one enclosure and shove them into another (without regarding order even) and be reasonably assured that your data will still be there.
Don't run cron jobs on NAS. Bad, bad!!! ;)
You don't need to run slocate on a system you never use for interactive processing.
Hell, don't run anything not directly related to moving data in and out of the system. Demand-based load is easy to model and there's less chance it'll fail unexpectedly (like when you're on vacation or something).
Software RAID is documented. If it fails, you can plug the drives into another system that understands the RAID format and get at the data. Hardware RAID is often propietary and all-or-nothing. You're not going to get much help on recovering your data from Promise or Adaptec when one of your cards go south. They'll say: "But didn't you keep recent backups???" (which is The Truth (tm) but still...)
Seriously, ATI cards suck to support. I don't recommend them to anybody no matter what OS they use.
Unless we're talking about like a R200-based platform (R8500, 9100, 9000Pro, 9200) which is pretty well understood and should be support by Windows HCL and Linux OSS drivers completely (incl. Xinerama/tv-out)
Anything newer than that is a crapshoot.
And you can tell ATI feels this way too. You know the FireMV line... their uber-stable flagship line of workstation multi-monitor visualization cards? All R200-based chips. They managed to shove 4 onto a board with a single passive heatsink and tons of texture memory. They leave the R300 and R400 cards for the Quadro line (w/certain features disabled) and the enthusiast boards (where crashes are expected anyway).
Get a real job, cuntwhack.
cp much?
*jumping up and down excitedly*
There are MATH SYMBOLS in the CLOUDS!!!
*gleeeee*
hahahaha... that was funny.
Excel is for the VISUAL EDITING of a limited set of datapoints with manageable dimensonality.
You aren't supposed to try to load your whole dataset at once into it, only a representative subset. Why would you use an application that tries to load every single datapoint into memory at once just so you can run batch processing type functions that operate on subsets at the data at a time? It's not like you are going to tweak any individual cell. It just seems ass-backwards.
No, there are plenty of better tools. For example, Programmer's Notepad or Texpad, which will allow you to visually examine the head -1 to see the exact column layout and make a good guess as to the seperator between fields of various types.
If your error is in the middle, (detected by WHICH program, I might add? How would you scan that many lines in Excel visually to find that problem anyway?) you could just use a sed statement with a line notation (or an expression that MATCHES the kinds of errors you're having) to elide the ill-constructed line.
If you can't reasonably expect to spot the problem by visually scanning in Excel over the cells because you've got datasets that large, then you shouldn't be using a visual tool anyway.
... can't work their way around a copy of R or Scilab (free), then I think they should be fired.
That's like a administrative assistant who can't speak english but can sign ASL really well. *eye roll*
It's called head. And tail.
Head and then open in Excel. Why would you try to open the whole thing at once?
Use tail to get an idea of the range of record IDs or whatever.
nt
What are you, a fucking imbecile?
It's called awk and grep. Jesus fucking christ.
If you deal with log files on a daily basis then you better learn to use some decent text processing tools.
If you're doing any kind of engineering analysis in Excel, you need to learn some new tools.
It's called Matlab. If that's out of your reach, there's Scilab. Anything but Excel. Christ.
That's like repairing a computer with a fisher price mallet.