unless GIMP could also support spot color. Not everyone can afford full four-color printing, but some of us might be interested in something simpler that could leverage the colorspace work. But no one wanted to tackle that "for fun" since there are certain legal issues involved there (*cough* PANTONE *cough*).
Not for nothing but, typically you let the printer convert from RGB colorspace to CYMK, since it tends to have the best feeling for that. You should make sure your monitor is calibrated for a profile your printer understands though, so the RGB sent to it is the RGB you saw on your screen.
Unless you're one of those people who really like to take control of their black levels. Or you have an offset printer. Oh, I didn't think so.
You need a workflow. (No one does that in design or desktop publishing anyway).
Step 1) Work on rasters (GIMP, PS, scanners, whatever) Step 2) Lay out vector layers, integrate rasters for backdrops, matted textures, etc. (Inkscape, KDraw, etc.) Step 3) Take groups of vector layers rasterized at a high resolution, reimport them into (GIMP, Krita), final composite.
This process may be more complicated and have more flows in and out depending on the size and scope of your end product.
Also keep in mind GIMP has rudimentary support for vectors in terms of manipulatable paths (which can be rasterized on demand).
An integrated product would be interesting, but I think it'd also be limiting (too many options and tools to expose simultaneously, confusing "raster or vector" layer context questions...)
I never use the fucking circle tool. Ever. In Photoshop. I use the path tool there, and I learned PS before the GIMP. So I, for one, am GLAD they refuse to add a button for it. Learn to use paths, and then I don't have to look at your shitty, rasterized attempts at shoehorning PS as a diagramming tool.
Why the hell do you need a circle tool anyway? I want you to think real hard before you answer. If you start with a blank canvas in Photoshop and build up a picture by starting with a circle tool, I'm not really sure what to say other than you're using the tool wrong.
Line tool is an understandable complaint. It's a common enough op that you shouldn't have to round trip through a Path/Stroke to do it. But circle?
Inkscape and Gimp don't step on each other's toes.
Inkscape doesn't have airbrush tools or a blur filter.
Gimp doesn't have a mini-copy of Illustrator bundled into it either (remember PS 6.0?)
Let's consider the cases where you might want to draw a circle in the GIMP. Oh wait, there isn't a real good reason. Why the hell would you want a special purpose tool that only serves to rasterize (and trash) the layer below unless it was a drawing tool like a pen or eraser? IT'S CALLED A PATH. It's in Photoshop too, you know. You got your polylines, circles, rounded rectangles, beziers, arcs, etc. You create them, manipulate them, attach them to guides, and when you want to turn them into pixels, THEN YOU STROKE OR FILL THEM.
I like multi-windowed applications. I have two monitors and a proper desktop manager. When I'm doing graphics, I need to be able to make things big, small, float this, drag this tab into here, get rid of that space-consuming menu (I'd rather context-right click).
... no one is going to implement a GUI toolkit that is designed for both embedded and desktop use with a garbage collecting language runtime. If you knew anything about writing cross-platform code (that works on platforms with varying memory spaces, models, with or without MMUs) you'd know that it's not really in the cards. Never mind that all the APIs that it'd bind to are written in C or Objective C. (XLib, Win32/DirectX, xGL, Quartz).
Let me guess, you're in a degree program, or have just recently graduated, or you work at Ericsson. Am I right?
Well, for one thing, if I were a GIMP developer I wouldn't want to add anything that might encourage people to add even more offset shadows or halos into images. It's the lens-flare mania of the 21st century.
In any case I'll bet they're going to work on a generic realtime filter application framework first, and implement the parameterized shadows as an implementation in that. GEGL is a key to making that happen.
And for the record, you really shouldn't shadow or matte until you're positive about how you want things laid out (typically you're going to need to go in and hand modify or gradient your layer mask in a shadow layer anyway).
It'd be nice for doing previews though.
I think extending layer grouping so that you can applying transformations to them is probably a more important thing to have first.
760MP - For the Athlon MPs. Bitching chipset, loved it. 8131/8111 - For the early Opterons. Dual PCI-X busses and all sorts of other goodies. 8151/8111 - You need AGP? Okay, so you used this.
They don't have a native PCIe chipset, although typically you say an NForce MCP or Radeon XPress attached to a free HT lane doing that job.
That's the beauty of AMD64 and HT, you can mix and match NBs and SBs (although it doesn't really make sense to call them that, it's an Intel-ism, NBs are like periphial bus hubs, and SBs are like legacy/media device hubs).
In the business world, you used an AMD 8131 and 8111. End of story. And later, the 8151. It was rock solid, gave you two PCI-X busses (later AGP/PCIe with 8151), what more could you want?
Well, you couldn't do SLI, so that's when NForce Pros started appearing in conjunction with the 8131s.
Anyway. VIA was always the budget option. You avoid VIA if you wanted stability and performance. For intel OR amd.
It's statistics. A certain percentage of potential CPU buyers only want the product that gets the best benchmark at any cost. Another percentage want the best CPU power for the money. Another percentage try to minimize cost and accept a minimum level of performance. Other percentages make brand motivated decisions if their financial/horsepower needs are not limiting factors, otherwise they'd be in the first three group. A large percentage make a decision based on market availability (essentially random).
The brand motivated choice component is especially significant in a market where the products are largely interchangable. From an end-user standpoint (not enthusiasts, system builders, or commercial/industrial users), Core 2 and A64 are equivalent products. Like two brands of shampoo.
Try to get a refurbed ihp series. H320/H340 is also decent.
Driving factors are: * USB Mass storage support * Excellent battery life * Best sound quality of any portable reviewed, ihp series also have an optical line out * Install rockbox, get even more features (play gameboy games and listen to music at the same time, FLAC support, etc.)
One of these days I'm going to buy up a couple for spare parts in case mine dies. There has not been a better portable since (except maybe the Cowan/JetAudios, but they have reliability issues or so I've heard)
Find a refurbished iRiver ihp-140 or H340. Install Rockbox.
Load up with (FLAC, SHN, MPC, WAVPACK, OGG, MP3, M4A) and enjoy lossless playback with pure-integer decoders and a really nice DAC to boot Oh, and the iHP-140 has an optical output which is _very_ useful if you have digital inputs on a custom DAC or amp.
It uses IOKit to walk a device tree looking for fan-like things. It enumerates them, and lets you set or read a series of RPM thresholds (min, max, target). The GUI is built on top of the CLI program that does all that.
IIRC the fan controllers on the macbook pros are PWM, not voltage controlled. Most fan controllers with an I2C interface since, I can't remember, have been PWM in my experience. This is a good thing, because running a fan at reduced voltage produces a non-linear relationship with power consumed and air moved. PWM is more linear since it uses the momentum of the blades to keep it running at a target speed, pulsing power into it as it slows down. I've also heard PWM increases the fan's life expectancy... but I don't know if there's any merit to that.
... that every site you find that claims to have voyeur style videos (with the subjects not knowing they are on camera) are fake.
Fake. Fake. Fake.
Do you know how much legal liability there is if you try to make money off of something where the subjects are unwilling participants? Not enough to be worth the effort to set up a billing system and charge people access, I assure you.
Well here's the current situation: You can use it if you want. UFS1 is supported R/W. UFS2 exists as read-only.
However ext3 is capability identical to FFS with additional journaling options. In the beginning linux was using minix/xiafs. ext was introduced to help transition from that while bringing modern features to the table. Each evolution on the FS has been forward compatible to ease transition.
extX, reiser, jfs and xfs. Each of them have a purpose:
extX: simple, low-overhead, modest size limits, online resize. reiserfs: more efficient storage of directories, small files, etc. An attempt to bring new techniques to the table like plugins and support for extended metadata and indexing. jfs: an import from AIX that had support for larger volumes than EXT3 did at the time. More efficient for large files. xfs: an import from SGI that had support for large volumes, stripe sets, and online inode/block resizing. More efficient for large files.
There are reasons to have different file systems depending on the needs of your data. extX fulfills the same roles as FFS and does a good enough job that trying to get FFS to "work" under linux is not worth the effort except for cases of quorum disks and other chicanery. ReiserFS, JFS, and XFS (and your other flavor-of-the-month types) all have legitimate uses in various circumstances (typically when dealing with really really big volumes, big files, databases, or lots of tiny files).
Woo... snapshots. *blink* (okay, so apparently yes, ext3 now comes with the 'lvm enhancement' patches that allow it to flush and lock operations during snapshot creation to avoid inconsistency after the fact)
You _can_ install more than one version of a library system wide, and a package that depends on a specific version number (or range) can specify that explictly in the package itself (with version comparator operators) and also have that enforced at dlopen time.
I know that I have 3 different versions of libstdc++ installed (to support programs written over the years), and it doesn't create a problem.
Packagers don't like bundling a library with more than a few apps. It makes it difficult to respond to security vulnerabilities in them. How many applications from closed-source vendors issued patches to address the ZLIB vulnerability a year ago? There were a lot of shops using that code at the time (since it was BSD licensed), and a good chunk of them probably didn't realize it... it wasn't anywhere in the design docs, a developer could just cut and paste code a few modules into the source tree.
Look at mplayer. Good tool. But very frustrating how you can't upgrade to the latest ffmpeg and have mplayer take advantage of it. There's no "protocol" between mplayers command line and the internals of the bundled ffmpeg; they are too tightly coupled.
Can't use it on a live filesystem. No guarantee. Now if you use a volume manager you can create snapshots and back those up instead. Unfortunately most filesystems don't have a way of being told that a snapshot is being taken, and to checkpoint themselves. With the exception of XFS. I think there's a patch for ext3 to do this as well, but I don't know which distros include it by default.
I am of the opinion that the safest route is to do a backup at the mounted level of the filesystem from a snapshot from userspace (with any database services quiesced, or not backed up by this procedure). Pick the tool that preserves metadata best and has good support for incrementals (stores CRCs if possible).
Slashdot Mirror
unless GIMP could also support spot color. Not everyone can afford full four-color printing, but some of us might be interested in something simpler that could leverage the colorspace work. But no one wanted to tackle that "for fun" since there are certain legal issues involved there (*cough* PANTONE *cough*).
Not for nothing but, typically you let the printer convert from RGB colorspace to CYMK, since it tends to have the best feeling for that. You should make sure your monitor is calibrated for a profile your printer understands though, so the RGB sent to it is the RGB you saw on your screen.
Unless you're one of those people who really like to take control of their black levels. Or you have an offset printer.
Oh, I didn't think so.
You need a workflow. (No one does that in design or desktop publishing anyway).
Step 1) Work on rasters (GIMP, PS, scanners, whatever)
Step 2) Lay out vector layers, integrate rasters for backdrops, matted textures, etc. (Inkscape, KDraw, etc.)
Step 3) Take groups of vector layers rasterized at a high resolution, reimport them into (GIMP, Krita), final composite.
This process may be more complicated and have more flows in and out depending on the size and scope of your end product.
Also keep in mind GIMP has rudimentary support for vectors in terms of manipulatable paths (which can be rasterized on demand).
An integrated product would be interesting, but I think it'd also be limiting (too many options and tools to expose simultaneously,
confusing "raster or vector" layer context questions...)
I never use the fucking circle tool. Ever. In Photoshop. I use the path tool there, and I learned PS before the GIMP.
So I, for one, am GLAD they refuse to add a button for it. Learn to use paths, and then I don't have to look at your shitty, rasterized attempts at shoehorning PS as a diagramming tool.
Why the hell do you need a circle tool anyway? I want you to think real hard before you answer.
If you start with a blank canvas in Photoshop and build up a picture by starting with a circle tool, I'm not really sure what to say other than you're using the tool wrong.
Line tool is an understandable complaint. It's a common enough op that you shouldn't have to round trip through a Path/Stroke to do it.
But circle?
Inkscape and Gimp don't step on each other's toes.
:-)
Inkscape doesn't have airbrush tools or a blur filter.
Gimp doesn't have a mini-copy of Illustrator bundled into it either (remember PS 6.0?)
Let's consider the cases where you might want to draw a circle in the GIMP.
Oh wait, there isn't a real good reason. Why the hell would you want a special purpose tool that only serves to rasterize (and trash) the layer below unless it was a drawing tool like a pen or eraser?
IT'S CALLED A PATH. It's in Photoshop too, you know. You got your polylines, circles, rounded rectangles, beziers, arcs, etc. You create them, manipulate them, attach them to guides, and when you want to turn them into pixels, THEN YOU STROKE OR FILL THEM.
The more you know.
Or xfig.
Or xv.
I like multi-windowed applications. I have two monitors and a proper desktop manager.
When I'm doing graphics, I need to be able to make things big, small, float this, drag this tab into here, get rid of that space-consuming menu (I'd rather context-right click).
What is with you people?
... no one is going to implement a GUI toolkit that is designed for both embedded and desktop use with a garbage collecting language runtime.
If you knew anything about writing cross-platform code (that works on platforms with varying memory spaces, models, with or without MMUs) you'd
know that it's not really in the cards.
Never mind that all the APIs that it'd bind to are written in C or Objective C. (XLib, Win32/DirectX, xGL, Quartz).
Let me guess, you're in a degree program, or have just recently graduated, or you work at Ericsson. Am I right?
Well, for one thing, if I were a GIMP developer I wouldn't want to add anything that might encourage people to add even more offset shadows or halos into images.
It's the lens-flare mania of the 21st century.
In any case I'll bet they're going to work on a generic realtime filter application framework first, and implement the parameterized shadows as an implementation in that. GEGL is a key to making that happen.
And for the record, you really shouldn't shadow or matte until you're positive about how you want things laid out (typically you're going to need to go in and hand modify or gradient your layer mask in a shadow layer anyway).
It'd be nice for doing previews though.
I think extending layer grouping so that you can applying transformations to them is probably a more important thing to have first.
760MP - For the Athlon MPs. Bitching chipset, loved it.
8131/8111 - For the early Opterons. Dual PCI-X busses and all sorts of other goodies.
8151/8111 - You need AGP? Okay, so you used this.
They don't have a native PCIe chipset, although typically you say an NForce MCP or Radeon XPress attached to a free HT lane doing that job.
That's the beauty of AMD64 and HT, you can mix and match NBs and SBs (although it doesn't really make sense to call them that, it's an Intel-ism, NBs are like periphial bus hubs, and SBs are like legacy/media device hubs).
In the business world, you used an AMD 8131 and 8111. End of story. And later, the 8151.
It was rock solid, gave you two PCI-X busses (later AGP/PCIe with 8151), what more could you want?
Well, you couldn't do SLI, so that's when NForce Pros started appearing in conjunction with the 8131s.
Anyway. VIA was always the budget option. You avoid VIA if you wanted stability and performance. For intel OR amd.
It's statistics. A certain percentage of potential CPU buyers only want the product that gets the best benchmark at any cost. Another percentage want the best CPU power for the money. Another percentage try to minimize cost and accept a minimum level of performance. Other percentages make brand motivated decisions if their financial/horsepower needs are not limiting factors, otherwise they'd be in the first three group. A large percentage make a decision based on market availability (essentially random).
The brand motivated choice component is especially significant in a market where the products are largely interchangable. From an end-user standpoint (not enthusiasts, system builders, or commercial/industrial users), Core 2 and A64 are equivalent products. Like two brands of shampoo.
A lot of people have different opinions on this subject, but this player is the best one1 &item=280036927578&ssPageName=STRK:MEWA:IT&ih=018
that has come out in the last 3 years. (Seriously):
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&rd=
Try to get a refurbed ihp series. H320/H340 is also decent.
Driving factors are:
* USB Mass storage support
* Excellent battery life
* Best sound quality of any portable reviewed, ihp series also have an optical line out
* Install rockbox, get even more features (play gameboy games and listen to music at the same time, FLAC support, etc.)
One of these days I'm going to buy up a couple for spare parts in case mine dies. There has not been a better portable since (except maybe the Cowan/JetAudios, but they have reliability issues or so I've heard)
Find a refurbished iRiver ihp-140 or H340.
Install Rockbox.
Load up with (FLAC, SHN, MPC, WAVPACK, OGG, MP3, M4A) and enjoy lossless playback with pure-integer decoders and a really nice DAC to boot
Oh, and the iHP-140 has an optical output which is _very_ useful if you have digital inputs on a custom DAC or amp.
It uses IOKit to walk a device tree looking for fan-like things. It enumerates them, and lets you set or read a series of RPM thresholds (min, max, target). The GUI is built on top of the CLI program that does all that.
IIRC the fan controllers on the macbook pros are PWM, not voltage controlled.
Most fan controllers with an I2C interface since, I can't remember, have been PWM in my experience.
This is a good thing, because running a fan at reduced voltage produces a non-linear relationship with power consumed and air moved. PWM is more linear since it uses the momentum of the blades to keep it running at a target speed, pulsing power into it as it slows down. I've also heard PWM increases the fan's life expectancy... but I don't know if there's any merit to that.
Just -- no.
Javascript is the exactly wrong language for doing anything AI-like. Go back to your silly ALICE bots.
... that every site you find that claims to have voyeur style videos (with the subjects not knowing they are on camera) are fake.
Fake. Fake. Fake.
Do you know how much legal liability there is if you try to make money off of something where the subjects are unwilling participants? Not enough to be worth the effort to set up a billing system and charge people access, I assure you.
I use an NVidia card with it's binary blob driver and I can play back like 8 videos at once (not very useful, but there it is)
So it's not linux itself, it's getting good drivers and making sure you use them.
Well here's the current situation:
You can use it if you want. UFS1 is supported R/W. UFS2 exists as read-only.
However ext3 is capability identical to FFS with additional journaling options. In the beginning linux was using minix/xiafs. ext was introduced to help transition from that while bringing modern features to the table. Each evolution on the FS has been forward compatible to ease transition.
extX, reiser, jfs and xfs.
Each of them have a purpose:
extX: simple, low-overhead, modest size limits, online resize.
reiserfs: more efficient storage of directories, small files, etc. An attempt to bring new techniques to the table like plugins and support for extended metadata and indexing.
jfs: an import from AIX that had support for larger volumes than EXT3 did at the time. More efficient for large files.
xfs: an import from SGI that had support for large volumes, stripe sets, and online inode/block resizing. More efficient for large files.
There are reasons to have different file systems depending on the needs of your data. extX fulfills the same roles as FFS and does a good enough job that trying to get FFS to "work" under linux is not worth the effort except for cases of quorum disks and other chicanery.
ReiserFS, JFS, and XFS (and your other flavor-of-the-month types) all have legitimate uses in various circumstances (typically when dealing with really really big volumes, big files, databases, or lots of tiny files).
Woo... snapshots. *blink*
(okay, so apparently yes, ext3 now comes with the 'lvm enhancement' patches that allow it to flush and lock operations during snapshot creation to avoid inconsistency after the fact)
Or do you mean murderers...
How does one aggregate channels together to feed such a stream? Who has such specialized routers?
You _can_ install more than one version of a library system wide, and a package that depends on a specific version number (or range) can specify that explictly in the package itself (with version comparator operators) and also have that enforced at dlopen time.
I know that I have 3 different versions of libstdc++ installed (to support programs written over the years), and it doesn't create a problem.
Packagers don't like bundling a library with more than a few apps. It makes it difficult to respond to security vulnerabilities in them. How many applications from closed-source vendors issued patches to address the ZLIB vulnerability a year ago? There were a lot of shops using that code at the time (since it was BSD licensed), and a good chunk of them probably didn't realize it... it wasn't anywhere in the design docs, a developer could just cut and paste code a few modules into the source tree.
Look at mplayer. Good tool. But very frustrating how you can't upgrade to the latest ffmpeg and have mplayer take advantage of it. There's no "protocol" between mplayers command line and the internals of the bundled ffmpeg; they are too tightly coupled.
Can't use it on a live filesystem. No guarantee.
Now if you use a volume manager you can create snapshots and back those up instead. Unfortunately most filesystems don't have a way of being told that a snapshot is being taken, and to checkpoint themselves. With the exception of XFS. I think there's a patch for ext3 to do this as well, but I don't know which distros include it by default.
I am of the opinion that the safest route is to do a backup at the mounted level of the filesystem from a snapshot from userspace (with any database services quiesced, or not backed up by this procedure). Pick the tool that preserves metadata best and has good support for incrementals (stores CRCs if possible).