Eliminating a fiat currency for a commodity-backed currency... and Getting rid of the IRS
That's a little extreme. This is the kind of stuff you see in websites with weird colored fonts of different sizes, centered on the page.
Not that I think it might be a bad thing to have some financial reform, but being so bold will not get him elected and not make him any friends in Washington, which HE WILL NEED.
the vast majority of USB video cameras are not UVC compliant. Even the expensive Philips chipset-derived models are in their own world.
UVC compliance is very recent and spotty.
There's 20-odd V4L/V4L2 drivers for linux, of which more than half are just pluggable webcam drivers (mostly USB, and the lone firewire generic)
There's some USB streaming chipset support for those external S-Video adapters and DVR devices, and the rest are PCI attached devices and the venerable BT848 driver.
But since the cameras are essentially fixed-focus NTSC CCDs with framegrabbers, USB bridge chips of the week and ad-hoc Atmel microcontrollers with random firmware tying it all together... it's no wonder the Chinese OEMs just roll their own protocol and driver.
Implement a published spec! That'd take testing beyond plugging it into the engineer's laptop to see if it works.
But notwithstanding: LGPL means you most definitely can use it. LGPL does not require releasing the source of apps that link to them; that's the whole point. Five minutes of google would have told you that. So that's no excuse.
The good people of iiitran have been translating them as fast as they can for some time now. Take a current event (pick a headline from it.slashdot.org), mix with a 4-koma format, shake, enjoy.
And I wouldn't call it fetishism. I mean... take XP Home. She's been reinvented into a lecherous, track-suit wearing, yaoi-fanficion writing spinster who can't help but corrupt her younger brother.
That's not fetisihm, that's characterization (lol):-/
1) Your software still looks like a 16-bit Windows application. I imagine the code isn't very portable to begin with. Hence your difficulty in porting. 2) GTK is your GUI target. If you need a C++-based library, then target wxWindows or QT (added bonus, you get Windows compatibility for free with those two). There aren't any other choices. It really isn't as complicated as you make it out to be.
Strangely compelling indeed. But they didn't have a "cool" mascot list this issue so they put them in the "lame" mascot list... What the fuck is Wired, PC Gamer now? Click here for more OS-TAN goodness (SFW) Original Japanese site (some links inside NSFW)
No. I mean that changing the meaning of Perl 5 sigils to be lexical would break existing Perl 4 scripts, and so this was not done. Perl 6 intends to do that, but Perl 6 seems a foregone conclusion now.
But Microsoft and 3rd party contributors to.NET will always skew the ecosystem around it to its own ends, even if it is an open standard. No one will care about ECMA-compliance, only the latest-version-of-.NET-on-the-latest-Windows-serve r compliance.
Because sometimes Ruby is too slow.:-( Both Perl and Ruby are really rad. And RAD. And they both operate on the ever-so-helpful principle of least surprise. Unlike PHP, or a lot of other languages.:-/
If there was one thing I don't like about perl (and I can totally sympathize from a language beauty POV), it's that sigils represent interpretation intent, and do not describe the base object.
I.E. $foo[bar] is a value in @foo not @foo[bar]. Which seems silly because the array slicing operator has list and value return forms ([5], vs. [3..5]) and that should dictate the interpretation. Other perl ops get to dictate return values... why the distinction? And it's because Perl 5 is backwards compatible with Perl 4 which didn't have lexical namespaces, and so the sigils got ALL FUCKED UP during the transition and it makes Perl 5 look ugly.:-(
Ruby on Rails before PHP or bare JSP
on
Beginning Ruby
·
· Score: 1
PLEASE
Let's use MVC for our large sites for fuck's sake.
There was a proliferation of sound APIs back when computers had clockspeeds under 1GHz and SSE took way too many cycles if it stalled. Nowadays we have SSE3 that can do DSP ops on like 16 samples at a time in one cycle, advanced cache technologies, multicore processors running at 2GHz+... these can handle environmental audio entirely in software for a very small slice of the CPU. Mixing 64 channels and applying simple FIR filters is child's play.
No reason to waste a PCI slot and have to deal with a propietary interface if you don't need it. All you need is an AC97 endpoint per speaker pair, or an optical out, and a decent stereo setup.
A decision was made early on in the process of DX10 that compatibility with NT 5.x would NOT be a design goal. Compatibility with NT 5.x was only relevant to Longhorn technologies that would be used on corporate servers -- specifically Windows 2003 Server -- as Longhorn Server would not be coming out for some time.
So, with that restriction lifted, they could look at ways to re-architect DX10 to better address concerns that they had with the existing model.
One issue that was previously difficult to address was that if you ran multiple monitors, you might try to run multiple Direct3D applications. But the API and driver model handled this sort of situation poorly, and one is reminded of the Windows 3.1 days. A poorly designed Direct3D application could starve other DirectX/Direct3D applications by not relinquishing control of the GPU (3d pipeline) often enough or allocating up all the free video memory (or allocating it burstily in varying amounts) which would cause other 3d apps to freeze, visually glitch, or have to deal with memory errors/timeouts.
DirectX 10 introduces a model where video memory and access to the GPU is managed like system memory and CPU scheduling. DirectX 10-compliant video drivers must provide primitives that conform to these new features.
In this fashion a DirectX 10 application can allocate as much texture memory as it wants; if it doesn't fit in the graphics card at display time, it is paged out to main memory (and if that's full), swapped out to disk just like anything else. And it can hammer on the GPU all it likes; if other apps try to use it, they will be given their fair-share timeslices and your rendering will be slowed down.
The Windows XP driver model has no infrastructure to allow for these features. The API could emulate them but I don't know how well that would work without some sort of hardware support in the card that I suspect is necessary for it to work correctly (especially with the virtual memory and paging in video RAM)
I doubt that feature even works at all with AGP. It's probably PCIe only.
Linux just isn't like that. Most of the time you don't go off downloading an app to "do something" unless it's like a web browser or office package or something. For most things it's all about configuration of what you have to make services available. Most stuff is installed when you installed the OS in the first place. If not, it's usually a completely managed process.
Installing apps on Linux is a process that goes something like this:
Prep: 0) Find out how your linux distro of choice installs software. (Is it APT or Synaptic? Yum? Other?) 1) Make sure you can install or update software using that tool. Follow examples on the websites specific to your distro to get used to this.
Getting Software: 1) Find the software that does what you want it to do. Read about people's experiences with it; often there's some choices instead of one defacto thing so you need to research if you don't want to be a guinea pig. This takes some web searching. 2) Check to see if the software is in your distro's repository already. It probably is. Use the tool from the prep-steps to install the software by name. OR 3) The software might be in an outside repository not supported by your distro. These repositories are your friend because they eliminate the potential configuration management nightmares of trying to support one-off-software and their dependancies on your own. For example, one popular 3rd party repository of software for Fedora is called LIVNA. There are many cool thing in there, and they manage all the little bits that make those cool things work. 4) Follow the instructions on the website for whatever repository to add that to your software installation tool so it can pull stuff from there. As in step 2, you can then just install that software by name.
OR
5) Take a chance, and download an RPM or DEB file from the software page directly. These will probably not install on their own, and require you to install other things to make them work. Or you might get lucky and they work out of the box. Give it a shot.
6)./configure, make, make install. But that's probably not for you.
is for some end-user to improve the server code so that they can support more than two clients on their leased server in a datacenter somewhere.
The server code is GODAWFUL. If a user can get it to scale on the limited resources he or she has access to, then Linden Labs can benefit directly from that.
When you buy a car, it's an expensive personal purchase. When it fails, it's immediately obvious and you mean have legal avenues to investigate to mitigate the issue.
When you make a security decision, it's usually a low-cost personal purchase. When it fails (say your identity gets stolen), the losses you might incur can greatly outweigh the initial investment in the technology, and you will little legal recourse against the vendor to make things right.
This is why I don't trust any commercial security product that isn't merely selling support or management tools. Because they've nothing to lose except my business.
Also, web browsers (by design) eat up arbitrary amounts of whitespace and turn it into a single space. So, nearly all Internet interactions (web design, comments in blogs, forum posts) there's no way to get that double space after the period to stick anyway even if you added it.
Like right here. You can get the same effect using character entities to insert non-breaking spaces if that's allowed in the particular forum or whatever ( )
Well that's interesting. It's useful if you want to be able to play DRM'd WMV10 video, which VLC can't play for obvious reasons.
Although I'd probably stick to the 3rd party WMV implementations for most of the other stuff if only because it'll all sit in one piece of media software.
Both USB and Firewire can do DMA. In fact, USB would not even be close to usable with removable hard drives or memory sticks if it didn't. The CPU doesn't get interrupted more often or do significantly more work in bulk transfer modes using either technology. What USB cannot do, is allow two non-host devices on the bus to talk to each other independant of the computer. All communications are to and from the host. Firewire (as it is related to the similarly capable SCSI standard) does allow that.
What usually makes the difference is that USB can't have conversations in both directions simultaneously (it's half duplex), which means that your bandwidth overall is reduced by response messages going from the host to the device to tell it "OK, send me more data". This reduces the effective bandwidth by about half. With firewire, you implement mass storage like a TCP stream, both sides send acks and updates in parallel at the full advertised speed. (This is assuming the firewire bus does not contain too many people trying to talk at once; it is still a common-bus with device-initiate which requires arbitration and back-off)
It's called Postscript. And JetDirect is the lingua franca of printer interfacing, but you only see that in network printers since it's a network protocol.
Unfortunately, you can't implement either of those technologies easily in a sub $100 printer which does all the processing in the host computer; the bus protocol to the printer is arbitrary at that point anyway, it just has to be able to tell the inkjet heads what to do and to know when to hit you up for more razors, I mean ink.
It's no wonder home/soho printers are a mess. They're just ink sale generators, everything else is secondary.
OTH: Samsung's entry level laser has ethernet and PS Level 3, and it's like $200 and change... spend a little, you get less hassle. No installation disks required for Windows XP, Linux and Mac... you can get a bit better performance though if you load the PPD.
Slashdot Mirror
The outer Xorg must be the multi-cursor variety. Bind the pointer/keyboard sets to each Xnest client to make sure they get dedicated focus.
Alternatively (if you can afford two monitors and VGA cards) set up independant X servers on each screen, and bind them to specific USB input devices.
I like the guy for standing for his ideals but:
...
Eliminating a fiat currency for a commodity-backed currency
and
Getting rid of the IRS
That's a little extreme. This is the kind of stuff you see in websites with weird colored fonts of different sizes, centered on the page.
Not that I think it might be a bad thing to have some financial reform, but being so bold will not get him elected and not make him any friends in Washington, which HE WILL NEED.
4k is the common base of the most widely used operating system page sizes. :-)
(1k being more popular for embedded systems that don't have HDs anyway)
the vast majority of USB video cameras are not UVC compliant. Even the expensive Philips chipset-derived models are in their own world.
UVC compliance is very recent and spotty.
There's 20-odd V4L/V4L2 drivers for linux, of which more than half are just pluggable webcam drivers (mostly USB, and the lone firewire generic)
There's some USB streaming chipset support for those external S-Video adapters and DVR devices, and the rest are PCI attached devices and the venerable BT848 driver.
http://en.wikipedia.org/wiki/USB_video_device_clas s
But since the cameras are essentially fixed-focus NTSC CCDs with framegrabbers, USB bridge chips of the week and ad-hoc Atmel microcontrollers with random firmware tying it all together... it's no wonder the Chinese OEMs just roll their own protocol and driver.
Implement a published spec! That'd take testing beyond plugging it into the engineer's laptop to see if it works.
You're just a party pooper.
Well, your app sounds nice under the hood.
But notwithstanding: LGPL means you most definitely can use it. LGPL does not require releasing the source of apps that link to them; that's the whole point. Five minutes of google would have told you that. So that's no excuse.
...from the telco to your distribution panel in your neighborhood, even if its' ethernet/PPPoE over fiber that you get on your end.
The good people of iiitran have been translating them as fast as they can for some time now. Take a current event (pick a headline from it.slashdot.org), mix with a 4-koma format, shake, enjoy.
:-/
And I wouldn't call it fetishism. I mean... take XP Home. She's been reinvented into a lecherous, track-suit wearing, yaoi-fanficion writing spinster who can't help but corrupt her younger brother.
That's not fetisihm, that's characterization (lol)
Gallery of Vista-tan
There are two competing designs for her, but the screw-in-head exotic girl seems to have won.
1) Your software still looks like a 16-bit Windows application. I imagine the code isn't very portable to begin with. Hence your difficulty in porting.
2) GTK is your GUI target. If you need a C++-based library, then target wxWindows or QT (added bonus, you get Windows compatibility for free with those two).
There aren't any other choices. It really isn't as complicated as you make it out to be.
Strangely compelling indeed. But they didn't have a "cool" mascot list this issue so they put them in the "lame" mascot list... What the fuck is Wired, PC Gamer now?
Click here for more OS-TAN goodness (SFW)
Original Japanese site (some links inside NSFW)
No. I mean that changing the meaning of Perl 5 sigils to be lexical would break existing Perl 4 scripts, and so this was not done.
Perl 6 intends to do that, but Perl 6 seems a foregone conclusion now.
But Microsoft and 3rd party contributors to .NET will always skew the ecosystem around it to its own ends, even if it is an open standard. No one will care about ECMA-compliance, only the latest-version-of-.NET-on-the-latest-Windows-serve r compliance.
Because sometimes Ruby is too slow. :-( :-/
:-(
Both Perl and Ruby are really rad. And RAD. And they both operate on the ever-so-helpful principle of least surprise. Unlike PHP, or a lot of other languages.
If there was one thing I don't like about perl (and I can totally sympathize from a language beauty POV), it's that sigils represent interpretation intent, and do not describe the base object.
I.E.
$foo[bar] is a value in @foo not @foo[bar]. Which seems silly because the array slicing operator has list and value return forms ([5], vs. [3..5]) and that should dictate the interpretation. Other perl ops get to dictate return values... why the distinction?
And it's because Perl 5 is backwards compatible with Perl 4 which didn't have lexical namespaces, and so the sigils got ALL FUCKED UP during the transition and it makes Perl 5 look ugly.
PLEASE
Let's use MVC for our large sites for fuck's sake.
Thanks.
There was a proliferation of sound APIs back when computers had clockspeeds under 1GHz and SSE took way too many cycles if it stalled. Nowadays we have SSE3 that can do DSP ops on like 16 samples at a time in one cycle, advanced cache technologies, multicore processors running at 2GHz+... these can handle environmental audio entirely in software for a very small slice of the CPU. Mixing 64 channels and applying simple FIR filters is child's play.
No reason to waste a PCI slot and have to deal with a propietary interface if you don't need it. All you need is an AC97 endpoint per speaker pair, or an optical out, and a decent stereo setup.
A decision was made early on in the process of DX10 that compatibility with NT 5.x would NOT be a design goal. Compatibility with NT 5.x was only relevant to Longhorn technologies that would be used on corporate servers -- specifically Windows 2003 Server -- as Longhorn Server would not be coming out for some time.
So, with that restriction lifted, they could look at ways to re-architect DX10 to better address concerns that they had with the existing model.
One issue that was previously difficult to address was that if you ran multiple monitors, you might try to run multiple Direct3D applications. But the API and driver model handled this sort of situation poorly, and one is reminded of the Windows 3.1 days. A poorly designed Direct3D application could starve other DirectX/Direct3D applications by not relinquishing control of the GPU (3d pipeline) often enough or allocating up all the free video memory (or allocating it burstily in varying amounts) which would cause other 3d apps to freeze, visually glitch, or have to deal with memory errors/timeouts.
DirectX 10 introduces a model where video memory and access to the GPU is managed like system memory and CPU scheduling. DirectX 10-compliant video drivers must provide primitives that conform to these new features.
In this fashion a DirectX 10 application can allocate as much texture memory as it wants; if it doesn't fit in the graphics card at display time, it is paged out to main memory (and if that's full), swapped out to disk just like anything else. And it can hammer on the GPU all it likes; if other apps try to use it, they will be given their fair-share timeslices and your rendering will be slowed down.
The Windows XP driver model has no infrastructure to allow for these features. The API could emulate them but I don't know how well that would work without some sort of hardware support in the card that I suspect is necessary for it to work correctly (especially with the virtual memory and paging in video RAM)
I doubt that feature even works at all with AGP. It's probably PCIe only.
Linux just isn't like that. Most of the time you don't go off downloading an app to "do something" unless it's like a web browser or office package or something. For most things it's all about configuration of what you have to make services available. Most stuff is installed when you installed the OS in the first place. If not, it's usually a completely managed process.
./configure, make, make install. But that's probably not for you.
Installing apps on Linux is a process that goes something like this:
Prep:
0) Find out how your linux distro of choice installs software. (Is it APT or Synaptic? Yum? Other?)
1) Make sure you can install or update software using that tool. Follow examples on the websites specific to your distro to get used to this.
Getting Software:
1) Find the software that does what you want it to do. Read about people's experiences with it; often there's some choices instead of one defacto thing so you need to research if you don't want to be a guinea pig. This takes some web searching.
2) Check to see if the software is in your distro's repository already. It probably is. Use the tool from the prep-steps to install the software by name.
OR
3) The software might be in an outside repository not supported by your distro. These repositories are your friend because they eliminate the potential configuration management nightmares of trying to support one-off-software and their dependancies on your own. For example, one popular 3rd party repository of software for Fedora is called LIVNA. There are many cool thing in there, and they manage all the little bits that make those cool things work.
4) Follow the instructions on the website for whatever repository to add that to your software installation tool so it can pull stuff from there. As in step 2, you can then just install that software by name.
OR
5) Take a chance, and download an RPM or DEB file from the software page directly. These will probably not install on their own, and require you to install other things to make them work. Or you might get lucky and they work out of the box. Give it a shot.
6)
is for some end-user to improve the server code so that they can support more than two clients on their leased server in a datacenter somewhere.
The server code is GODAWFUL. If a user can get it to scale on the limited resources he or she has access to, then Linden Labs can benefit directly from that.
When you buy a car, it's an expensive personal purchase. When it fails, it's immediately obvious and you mean have legal avenues to investigate to mitigate the issue.
When you make a security decision, it's usually a low-cost personal purchase. When it fails (say your identity gets stolen), the losses you might incur can greatly outweigh the initial investment in the technology, and you will little legal recourse against the vendor to make things right.
This is why I don't trust any commercial security product that isn't merely selling support or management tools. Because they've nothing to lose except my business.
Also, web browsers (by design) eat up arbitrary amounts of whitespace and turn it into a single space. So, nearly all Internet interactions (web design, comments in blogs, forum posts) there's no way to get that double space after the period to stick anyway even if you added it. Like right here. You can get the same effect using character entities to insert non-breaking spaces if that's allowed in the particular forum or whatever ( )
Well that's interesting. It's useful if you want to be able to play DRM'd WMV10 video, which VLC can't play for obvious reasons.
Although I'd probably stick to the 3rd party WMV implementations for most of the other stuff if only because it'll all sit in one piece of media software.
Both USB and Firewire can do DMA. In fact, USB would not even be close to usable with removable hard drives or memory sticks if it didn't. The CPU doesn't get interrupted more often or do significantly more work in bulk transfer modes using either technology.
What USB cannot do, is allow two non-host devices on the bus to talk to each other independant of the computer. All communications are to and from the host. Firewire (as it is related to the similarly capable SCSI standard) does allow that.
What usually makes the difference is that USB can't have conversations in both directions simultaneously (it's half duplex), which means that your bandwidth overall is reduced by response messages going from the host to the device to tell it "OK, send me more data". This reduces the effective bandwidth by about half. With firewire, you implement mass storage like a TCP stream, both sides send acks and updates in parallel at the full advertised speed. (This is assuming the firewire bus does not contain too many people trying to talk at once; it is still a common-bus with device-initiate which requires arbitration and back-off)
It's called Postscript. And JetDirect is the lingua franca of printer interfacing, but you only see that in network printers since it's a network protocol.
Unfortunately, you can't implement either of those technologies easily in a sub $100 printer which does all the processing in the host computer; the bus protocol to the printer is arbitrary at that point anyway, it just has to be able to tell the inkjet heads what to do and to know when to hit you up for more razors, I mean ink.
It's no wonder home/soho printers are a mess. They're just ink sale generators, everything else is secondary.
OTH: Samsung's entry level laser has ethernet and PS Level 3, and it's like $200 and change... spend a little, you get less hassle. No installation disks required for Windows XP, Linux and Mac... you can get a bit better performance though if you load the PPD.