Basically what it says...
on
SHA-1 Broken
·
· Score: 1
is that it's considered a munition if it's designed for military use. An expert review panel is supposed to make that decision. And this is only if the Secretary of Commerce or the DOJ say something.
Which they haven't... so... don't worry about.:-)
Not true.
on
SHA-1 Broken
·
· Score: 2, Interesting
Clinton signed a bill that ceased the definition of cryptographic algorithms as munitions. Now there is no strength requirements, checking by the NSA, nothing. Like since 96.
It'd be cool if it's Brock that gets incapicated somehow and Dr. V has to actually pull his shit together, take some valium, and get in his dad's mecha suit to wreak havoc on the Monarch or some shit.
LSI megaraid is another really decent options. Cards are between $100-$350 bucks, and get it with sata or scsi support, option for PCI-X, hardware raid-5 whole shebang. Excellent drivers.
You needed to install the kernel-unsupported RPMs from the (4th?) disc. It didn't show you it in the install because they didn't to encourage anybody to use something they couldn't support as easily. But if you wanted it you could have it. They even provided the user space tools by default (jfs-utils).
but you need to find the mojo fish. You have to walk around in the water near the top right of the screen and walk in a square like the electric slide. You might get into a random battle with a tentacle monster (so labeled, but it uses the river octopi sprites)
1) Fedora-like desktop. Of particular note: memory keys are auto-mounted thanks to dbus/HAL support and udev
2) Ability to use selinux MAC and auditing
3) New versions of OO, gimp, gtk, moz out of thje box...
4) Aaaand... there's not much else that stands out. Most stuff that works on 3 will work on 4 and vice versa, maybe requiring a SRPM re-build. It looks pretty much the same, still bluecurve with some tweaks. Not that it doesn't look good.
That is what we call stupid BIOS tricks. I mean, flash ROMs are getting so cheap you can fit an embedded system in there, which is what that is. I mean, if the IDE controller and VGA controller is onboard, then there's no need for device detection. You just 'do it'.
Intel is just planning on re-targeting their chipsets with builtin video as some kind of media platform like Centrino was for laptops. (Centrino just meant a Pentium M and a Intel-branded wireless mini-pci card pre-installed)
although looking at man 3 readline... I don't think you'd need a book to cover that.:-)
Sorry, I didn't read the book. But I mean there are lots of applications which are not GUI oriented... well so most of them are computing environments or expert systems but people pay a lot of money for them!;)
1) one thing make can't do is run tests that generate dependancies at runtime... it does it in one pass at the beginning. Since you're running it iteratively this isn't a big deal.
2) For a batch automation system, you'll need to use make -k, and if you need to, put targets in.DELETE_ON_ERROR if you don't do something like manually touching a status file at the end of a command.
3) If you have a dependancy chain of targets and you don't want to have to clean up explicitly (or you want your job to run entirely in phases), you can label intermediate targets with.INTERMEDIATE, and if make finishes processing these things in one invocation, it wil delete the outputs/status files when all the dependant jobs are run. If it doesn't make it, then it will be forced to restart from the preconditions.
4) Make sure to fully outline dependancies. If you need to somehow prevent two things from running in parallel, you need to create an artificial barrier with the script itself unfortunately. The easiest way to do this would be perl and IPC::SysV, I should think. You might know of some other shell tricks or opening a device that blocks like a FIFO... but it sucks that gnu make doesn't have it. (However HP-UX and SCO's make have a.MUTEX pseudo-target that prevents two things from being run in parallel... shame)
Cron + make is actually a pretty good solution. Why?
make can told to proceed as far as possible with missing results. If you keep running it every so often, it will eventually get all it's dependancies as soon as possible and produce the "final" result. (These results are intermediate files that just checkpoint progress... unless you are using a custom make test)
What's interesting is that you can ask make to treat "dependancies" as either a all-present or a do-in-order type of thing (or both). Even cooler is listing dependancies as functions which return "values" that are files that exist or do not exist to express transient effects. This of course means you need to run make periodically for it to re-asses the situation.
Make is not suitable when the process has a lot of constraints that are in flux. But it is quite suitable for do-stuff-as-soon-as-feasible batch processing.
If you can write all your steps as individual scripts, and you can build a map of dependancies, then you can write a single makefile which encapsulates all of this very easily. Moreover gnu make is nice because you can give it hints about what subtasks can and cannot be parallelized, and it will handle that for you.
Some people don't use the framebuffer drivers because they have a "better" xorg driver and they might be incompatible. So bootsplash doesn't work. What you can use is rhgb. When entering runlevel 5 it loads X ASAP during the boot process and has a special progress screen. When it's time to load XDM/GDM the greeter script kills rhgb but keeps the X session for itself. (This is important because if X went down and then up again, you'd have to sit through two screen blank-outs while the monitor gets re-probed)
Hello. Welcome to slashdot. Would you like a clue?
Compressor, Cleaner... say I wonder if I can download a free copy of those to run on my Solaris box. No? Well, it's back to handrolling an implementation from the ITU MPEG-2 reference documents.
All of them have the same document model, if you will. They employ a floating bar that while having a menu, largely is there in case you forget to right-click in an active area.
Same workflow ideas apply for all those tools and I feel it becomes re-inforcing.
That being said, many types of applications have no business using this model! For example, video/sound editors. (See Cooledit, Final Cut, Audacity and Kino as examples)... they've have got those UIs done right. Those applications are very "project" centric and thus should have a single window interface.
But I think the multiple doc+right click is really powerful when you are working on tasks where you often go back and forth between documents and it's very 2D-spatially oriented, you know?
Using linux/bsd as a base, you can have a custom image that runs on the machine. In one VT you have ica "always on". In one VT you have a limited environment with some kinda IM, firefox, whatever for browsing the internet/intranet, etc. This image could even come PXE. Ooooohh.... I get myself all tingly.
When you use the GIMP it definitely changes your workflow. Then you get very used to it.
Big idea:
The right-click menu is exactly the same thing as the toolbar menu + picture-specific menu.
Which means you can do anything by right-clicking. What ends up happening is that you stop thinking about trying to "find" the file menu in the corner. Instead you just right-click whereever you are in your active image, and anything you do in that menu is applied TO that image (save, merge, filter, whatever). I find to this be much less of a repetetious thing than having to shoot the mouse to the corner of the screen and navigate those menus.
Also, you will definitely want to dock all your options and stuff underneath your main toolbar (or create two, maybe put them on both sides of the screen). This is really, really helpful. Just open up ALL the dialogs but "windowshade" them in the toolboxes. This prevents any of them from unexpectedly showing up floating.
Unforuntaely in Windows, you can't tell it to remember to keep those one or two toolbars permanently on top and always in the same place. In Unix then you just take a picture, do maximize-available size, and presto, no overlapping windows.
I mean, the GIMP UI is really flexible. You'll want to make sure you set it up the way you like it, and keep it that way. It sucks that windows doesn't implement some features that it expects so that you can do things like freeze window locations, grouping windows together, or prevent them from overlapping and stuff.
But yeah, to re-iterate. 1) Right click means less moving mouse around 2) Customize your dialogs and toolboxes to keep things uncluttered. 3) Relies on window manager to keep dialogs and windows behaved (as this is the X11 way). Windows-port is working on MDI-like idioms to help out this problem
Slashdot Mirror
is that it's considered a munition if it's designed for military use. An expert review panel is supposed to make that decision. And this is only if the Secretary of Commerce or the DOJ say something.
:-)
Which they haven't... so... don't worry about.
Clinton signed a bill that ceased the definition of cryptographic algorithms as munitions. Now there is no strength requirements, checking by the NSA, nothing. Like since 96.
Where've you been?
It'd be cool if it's Brock that gets incapicated somehow and Dr. V has to actually pull his shit together, take some valium, and get in his dad's mecha suit to wreak havoc on the Monarch or some shit.
LSI megaraid is another really decent options. Cards are between $100-$350 bucks, and get it with sata or scsi support, option for PCI-X, hardware raid-5 whole shebang. Excellent drivers.
You needed to install the kernel-unsupported RPMs from the (4th?) disc. It didn't show you it in the install because they didn't to encourage anybody to use something they couldn't support as easily. But if you wanted it you could have it. They even provided the user space tools by default (jfs-utils).
rpm --import http://freshrpms.net/packages/RPM-GPG-KEY.txtm -i http://ftp.freshrpms.net/pub/freshrpms/fedora/linu x/3/freshrpms-release/freshrpms-release-1-1.fc.fr. noarch.rpm
rp
yum install mplayer
7+ year sysadmin AND watching WMV porno.
And while the Nvidia accelerated drivers work fine, I don't run Half Life. I use that for q3a + mods.
but you need to find the mojo fish. You have to walk around in the water near the top right of the screen and walk in a square like the electric slide. You might get into a random battle with a tentacle monster (so labeled, but it uses the river octopi sprites)
1) Fedora-like desktop. Of particular note: memory keys are auto-mounted thanks to dbus/HAL support and udev
2) Ability to use selinux MAC and auditing
3) New versions of OO, gimp, gtk, moz out of thje box...
4) Aaaand... there's not much else that stands out. Most stuff that works on 3 will work on 4 and vice versa, maybe requiring a SRPM re-build. It looks pretty much the same, still bluecurve with some tweaks. Not that it doesn't look good.
2 + 3 == cats
It's almost as beautiful as e ^ pi * i + 1 = 0
That is what we call stupid BIOS tricks. I mean, flash ROMs are getting so cheap you can fit an embedded system in there, which is what that is. I mean, if the IDE controller and VGA controller is onboard, then there's no need for device detection. You just 'do it'.
Intel is just planning on re-targeting their chipsets with builtin video as some kind of media platform like Centrino was for laptops. (Centrino just meant a Pentium M and a Intel-branded wireless mini-pci card pre-installed)
Modern unicies broke away from crypt(1) a _long_ time ago and advocated the use of passphases vs. passwords. Ever hear of Jack the Ripper?
Why is it that suddenly now when a microsoft employee "discovers" this last year it's news? I feel sorry for the guy.
Fact: Did you know that Windows 2000 based operating systems support pass-PHRASES of up to 127 characters including spaces...
/etc/pam.d/system-auth ---
... snip ...
/etc/security/policy.conf ---
... snip ...
... snip ...
Wow that's impressive.
Oh wait... no it isn't.
---
password required pam_unix.so md5 remember=5
---
CRYPT_ALGORITHMS_ALLOW=1,2a,md5
CRYPT_DEFAULT=1 #Compatible with BSD/Linux MD5
Because you know, all those ancient Unix systems kept you from using passwords more than 8 letters long.
although looking at man 3 readline... I don't think you'd need a book to cover that. :-)
;)
Sorry, I didn't read the book. But I mean there are lots of applications which are not GUI oriented... well so most of them are computing environments or expert systems but people pay a lot of money for them!
1) one thing make can't do is run tests that generate dependancies at runtime... it does it in one pass at the beginning. Since you're running it iteratively this isn't a big deal.
.DELETE_ON_ERROR if you don't do something like manually touching a status file at the end of a command.
.INTERMEDIATE, and if make finishes processing these things in one invocation, it wil delete the outputs/status files when all the dependant jobs are run. If it doesn't make it, then it will be forced to restart from the preconditions.
.MUTEX pseudo-target that prevents two things from being run in parallel... shame)
2) For a batch automation system, you'll need to use make -k, and if you need to, put targets in
3) If you have a dependancy chain of targets and you don't want to have to clean up explicitly (or you want your job to run entirely in phases), you can label intermediate targets with
4) Make sure to fully outline dependancies. If you need to somehow prevent two things from running in parallel, you need to create an artificial barrier with the script itself unfortunately. The easiest way to do this would be perl and IPC::SysV, I should think. You might know of some other shell tricks or opening a device that blocks like a FIFO... but it sucks that gnu make doesn't have it. (However HP-UX and SCO's make have a
Cron + make is actually a pretty good solution. Why?
make can told to proceed as far as possible with missing results. If you keep running it every so often, it will eventually get all it's dependancies as soon as possible and produce the "final" result. (These results are intermediate files that just checkpoint progress... unless you are using a custom make test)
What's interesting is that you can ask make to treat "dependancies" as either a all-present or a do-in-order type of thing (or both). Even cooler is listing dependancies as functions which return "values" that are files that exist or do not exist to express transient effects. This of course means you need to run make periodically for it to re-asses the situation.
Make is not suitable when the process has a lot of constraints that are in flux. But it is quite suitable for do-stuff-as-soon-as-feasible batch processing.
If you can write all your steps as individual scripts, and you can build a map of dependancies, then you can write a single makefile which encapsulates all of this very easily. Moreover gnu make is nice because you can give it hints about what subtasks can and cannot be parallelized, and it will handle that for you.
in cron.daily... /working/dir /working/dir/Makefile -
make -j $NCPUs -C
all: tasks/1 tasks/2 tasks/3
tasks/1:
foo bar baz
frob fritz
touch tasks/1
tasks/2: tasks/2.1 tasks/2.2 some_make_test(tasks/2.3)
bar baz qyzzy and touch tasks/2
etc. etc. etc.
Some people don't use the framebuffer drivers because they have a "better" xorg driver and they might be incompatible. So bootsplash doesn't work. What you can use is rhgb. When entering runlevel 5 it loads X ASAP during the boot process and has a special progress screen. When it's time to load XDM/GDM the greeter script kills rhgb but keeps the X session for itself. (This is important because if X went down and then up again, you'd have to sit through two screen blank-outs while the monitor gets re-probed)
Hello. Welcome to slashdot.
Would you like a clue?
Compressor, Cleaner... say I wonder if I can download a free copy of those to run on my Solaris box.
No? Well, it's back to handrolling an implementation from the ITU MPEG-2 reference documents.
I guess mjpegtools is USELESS then...
And to comment on the "shift perspective"... it seems a lot of "creative" apps are going down this path when appropriate. Examples:
gimp - photo manip.
sodipodi - illustrator-like tool
dia - visio-like tool
gaim - IM/IRC client
All of them have the same document model, if you will. They employ a floating bar that while having a menu, largely is there in case you forget to right-click in an active area.
Same workflow ideas apply for all those tools and I feel it becomes re-inforcing.
That being said, many types of applications have no business using this model! For example, video/sound editors. (See Cooledit, Final Cut, Audacity and Kino as examples)... they've have got those UIs done right. Those applications are very "project" centric and thus should have a single window interface.
But I think the multiple doc+right click is really powerful when you are working on tasks where you often go back and forth between documents and it's very 2D-spatially oriented, you know?
Using linux/bsd as a base, you can have a custom image that runs on the machine. In one VT you have ica "always on". In one VT you have a limited environment with some kinda IM, firefox, whatever for browsing the internet/intranet, etc. This image could even come PXE. Ooooohh.... I get myself all tingly.
Go back 5 years. Put Illustrator, Photoshop, Premiere, and Pagemaker side by side.
They all looked and behaved completely differently.
NOW they intergrate, look, and behave similarly. Sort of. And they "integrate" by copying features out of each other.
I wouldn't use the Adobe products as an example of how to make a consistant software suite.
When you use the GIMP it definitely changes your workflow. Then you get very used to it.
Big idea:
The right-click menu is exactly the same thing as the toolbar menu + picture-specific menu.
Which means you can do anything by right-clicking. What ends up happening is that you stop thinking about trying to "find" the file menu in the corner. Instead you just right-click whereever you are in your active image, and anything you do in that menu is applied TO that image (save, merge, filter, whatever).
I find to this be much less of a repetetious thing than having to shoot the mouse to the corner of the screen and navigate those menus.
Also, you will definitely want to dock all your options and stuff underneath your main toolbar (or create two, maybe put them on both sides of the screen). This is really, really helpful. Just open up ALL the dialogs but "windowshade" them in the toolboxes. This prevents any of them from unexpectedly showing up floating.
Unforuntaely in Windows, you can't tell it to remember to keep those one or two toolbars permanently on top and always in the same place. In Unix then you just take a picture, do maximize-available size, and presto, no overlapping windows.
I mean, the GIMP UI is really flexible. You'll want to make sure you set it up the way you like it, and keep it that way. It sucks that windows doesn't implement some features that it expects so that you can do things like freeze window locations, grouping windows together, or prevent them from overlapping and stuff.
But yeah, to re-iterate. 1) Right click means less moving mouse around 2) Customize your dialogs and toolboxes to keep things uncluttered.
3) Relies on window manager to keep dialogs and windows behaved (as this is the X11 way). Windows-port is working on MDI-like idioms to help out this problem
When will Photoshop add something useful to the right-click context menu for those of us who are NOT using an Apple mouse? GOD!!!