Why would I pay $60/mo. for a service that's *hoping* to promise 150K/50K when loaded, doesn't allow "bandwidth hogs" such as streaming video or non-personal web sites, and has 0.5sec ping times that are going to make web browsing (how many server look-ups per page?) horrible?
I'm just getting used to the idea of having to pay $60/mo for IDSL (too far for ADSL) but, at least it's guaranteed 144K/144K with fast ping and no usage restrictions!
That's certainly one of the obvious possibilities, but the truth undoubtedly much more complex.
There are going to be many beneficial and detremental aspects to any genetic feature, and which of those dominate is going to change over time. Many features start out with one primary purpose/benefit which then gets subsumed over time by an alternative use as the environment or other factors change. For example, ears evolved from gills, and while ears no longer help us breath underwater, gills surely did have some benefit in picking up vibrations... Similarly a long neck may have evolved primarily under selective pressure as an efficient way to get rid of body heat, then over time the benefit of lazy grazing may have become more important, finally (in times of plenty, say) to become more important as a means sexual attraction.
xanim doesn't fully support MPEG-1 - it's not buggy (not that xanim doesn't have bugs in other formats) but just that it only supports MPEG key frames, not intermediate ones.
Try mtv, smpeg, xmovie, LAMP..
If you want decent fullscreen support on a slower speed machine (as you would get in Windows), then you need XFree 4.0 with the Xv extension and a player that supports it. Xv supports shared memory transfer of YUV images (MPEG decoder output) from user space directly to the graphics card memory, and uses the graphics card's hardware YUV-to-RGB conversion and scaling support.
BTW, there's only a few cards (such as Matrox g400) that have Xv driver support yet.
If you don't have Xv support, then second best would be a player like LAMP that supports DGA (direct video memory access under XFree).
From what I've seen every day stuff costs pretty much the same in Canada as the US, so it's not valid to say $1 US = $1 CAN - you DO have to take the exchange rate into account. That $40 US sweater will cost you $40 US ($60 CAN) in Canada.
Housing costs do seem to be generally cheaper in Canada, as does auto insurance (presumably because you don't sue each other all the time like the dickheads here do), but I still don't think that a 2/3 salary ($70-80K CAN vs $70-80K US) is going to give you have quite the same comfort of lifestyle.
avifile may read divx's, but it certainly doesn't work for all windows video CODECs. Have you ever tried getting it to use one other than those it comes bundled with - I hav't been able to get a single additional one to work - then all fail in different ways.
Still, if you do want to use avifile, aviplay and XMPS are not the best players. Try LAMP or XTheatre instead.
There are better options for MPEG also. SMPEG only works for MPEG-1 (as does mtvp). For MPEG-2, try xmovie, xine, or the VideoLan client.
There's also at least 3 Open Source divx (i.e. MPEG-4) CODEC efforts that I'm aware of - I submitted the story yesterday, but it was rejected.
Isn't there still a large salary difference between what a software engineer can make in the US vs Canada? With a bit of experience it's very easy to make $70-80K+ in the US, or a lot more if you're a contracter. How easy would it be to make the same (say $120K CAN) in Canada? I'm not talking top salaries, but rather what a typical experienced guy can expect...
Agreed, there may be other advantages to living in Canada, but financially it seems a loss.
You talk like they'd be getting something rather than just having less taken away.
Forget tax "cuts" (i.e. adjustments to the current screwed up system), and justify this: Why should a person who earns more than someone else pay more in taxes? Government enforced philanthropy?
Even with a flat $ (forget %) income tax, wealthy people would still be paying WAY more in taxes by way of sales tax.
Tax the rich only makes sense if you're willing to admit it's nothing to do with being fair - it's about socialism.
There's not the symmetry between Linux and Windows experience that you seem to imply. Windows was built for the masses, and tries to hide detail from you, but Linux does the reverse. Linux is built by techies for techies - people who happily trade ease-of-use for power and flexibility; people who not only are capable of looking under the hood when things break, but usually actually enjoy doing so! Does every Windows user have the potential to be a Unix administrator (i.e. Linux user)? Nah....
I initially downloaded 7.1 as an iso image at work and burned it to a CD-R, but it was so flaky I couldn't even install it properly. I ended up buying a mass produced version from Cheapbytes which was fine...
Whatever the reason, if it's a clean install it sounds like something's corrupted.... Is that the only problem you're having?
Re:infrared critter detection
on
Quickie Twister
·
· Score: 1
Excellent!
These are the best racoon pictures I have seen on slashdot today.
Did you upgrade from some earlier version of Linux? Perhaps you're somehow using an earlier version of the dynamic linker rather than the one that came with 7.2?
I just installed 7.1 (not 7.2) and it's got a lot of rough edges. Harddrake segaulted in some CD-ROM detect routine (I installed off CD), Sounddrake failed to detect my sound system, or correctly configure it when I specified everything (sndconfig worked though). The KDE/GNOME menu update/sync stuff fails miserably (best to disable it). The emacs provided has been patched to hardcode Alt=Meta (I downloaded a normal version)...and plenty of other minor inconveniences that would probably be a huge pain for someone new to Linux. It may be a pretty nice distro, but IMO not yet ready for Windows weenies...
Ah, but what if it could be a better slashdot? Surely you don't believe it has achieved a unimprovable state of excellence?
There are many things that make slashdot what it is, but I don't know that the details of story selection are really a huge part of that (other than an annoying part such as when rejected submissions turn up days later as "news" or the 101th one-click-patent story gets run).
For my money, the real flavor and value of slashdot comes from the collective personality and knowledge of the posters more than anything else.
I don't see it makes a difference whether/. is Rob's baby or a commercial endeavor - it's a news (for nerds) site, and should make an effort to make sure that the stories are in fact "news" and not unsubstantiated rumours (RH 7 has a zillion bugs).
What I'd really like to see, which would actually address the above is to get rid of/. article selection from the submission queue, and have the submission queue instead made available for moderation ("interesting story", "old news", "already appeared", "not true" etc).
People who want high quality timely news would view/. at a story level of 5, and others with more time on their hands could use lower levels.
The old fseek(), ftell() which used a long to represent the file offset are being replaced by fseeko() and ftello(), which use off_t, specifically as part of phasing in Large File Support (LFS). This API is available on Sun (others too, I'm sure) as well as Linux.
In order to enable fseeko/tello, you should compile your code with -D_LARGE_FILESOURCE, which will give you a default (currently 32bit) off_t. If you add -D_FILE_OFFSET_BITS=64, then off_t will be 64 bit, and fseeko/tello will be redefined as their 64 bit cousins. These definitions are part of the LFS standard.
glibc6 already has 64bit support, but of course you also need a new kernel (2.4) to get the >2GB support. AFAIK there's no 2.2.x backport.
BTW Mandrake 7.1 has a buggy stdio.h that doesn't support _LARGE_FILESOURCE (I believe it's been fixed in a more recent version). You can use -D__USE_UNIX98 instead to enable fseeko/tello support.
If you're using a temporary list to hold an arbitrary number of things prior to allocating an array to store/access them more efficiently it's useful to know how many elements you have, as it is if you're using one as a queue and want to trigger code based on high/low threshholds, or even if you're waiting for a list to become empty, but want to know how many items are still left... Perhaps more to the point though, a library writer (esp. a basic data structure library) shouldn't make lazy/sloppy assumptions about how it's going to be used.
I agree with you about C++. I think the problem isn't just programmers who don't fully understand some of the more complex features, but also incorrect and incomplete implementations of the lanuage.
I just took another look at SGI's version, but as before find more reasons to stay away than to use it...
You're right that it does specify performance characteristics, but they don't seem that desireable...I noticed that list::size() is listed as being O(N) rather than constant time! Would it really hurt the implementation to require a count++/-- when items are added or deleted? This may seem like a small gripe, but it makes the list class (one of the must useful basic types!) much less useful than it should be - I often use the equivalent size() function of my own list class assuming that it's essentially zero cost.
The other thing that hits me everytime I look at STL is the complexity vs the functionality provided... just take a look at the iterator invalidation semantics of basic_string! Am I meant to remember that stuff? It certainly seems to put an undue burdon on anyone having to maintain code.
If I thought that STL adoption was inevitable, then I might still grumble but start using it anyway, but considering how long it's been out and the current level of adoption, I think maybe that it has risen/sunk to it's own level, and will never be as ubiquitous as it could have been...
I've never seen any performance guarantees for the STL. AFAIK any implementation is free to implement the standard in any way they choose, and I'd be very surprised if they all (for example) chose to implement hash tables the same way. OTOH my hashtable uses insert-at-start chained overflow, so I know precisely what the performance characteristics are.
I don't know why you'd think my code has bugs or a hard to learn interface. I've been programming since probably before you were born, so I think I've got the hang of it by now!;-)
Your other points are equally dubious...
Which implementation of the STL do you claim is bug free - SGI's, HP's, GNU's? Whichever you use? Them all? The fact is that aspects of the STL String class can be formally proved to be unimplementable without bugs, which is why the Rope class is preferred.
STL well understood by all professional programmers? Hardly. In a Sun/C++ environment people are much more likely to have used Rogue Wave's classes than STL.
AFAIK (certainly at companies I've worked at), STL adoption is far from widespread. As I pointed out in another reply, even a well-designed modern C++ library such as Qt doesn't use it. I don't think GTK-- (the C++ GTK+ interface) does either. Maybe I'm not the only one to find it of limited value...
I'd agree with you if it wern't for the fact that I've yet to come across a library that used STL as part of it's interface! In fact, the only C++ (vs C) library I'm using right now is Qt which implements it's own datastructure classes!
Are there any/many libraries that you're aware of that do operate on STL types?
Slashdot Mirror
Why would I pay $60/mo. for a service that's *hoping* to promise 150K/50K when loaded, doesn't allow "bandwidth hogs" such as streaming video or non-personal web sites, and has 0.5sec ping times that are going to make web browsing (how many server look-ups per page?) horrible?
I'm just getting used to the idea of having to pay $60/mo for IDSL (too far for ADSL) but, at least it's guaranteed 144K/144K with fast ping and no usage restrictions!
StarBollocks.
That's certainly one of the obvious possibilities, but the truth undoubtedly much more complex.
There are going to be many beneficial and detremental aspects to any genetic feature, and which of those dominate is going to change over time. Many features start out with one primary purpose/benefit which then gets subsumed over time by an alternative use as the environment or other factors change. For example, ears evolved from gills, and while ears no longer help us breath underwater, gills surely did have some benefit in picking up vibrations... Similarly a long neck may have evolved primarily under selective pressure as an efficient way to get rid of body heat, then over time the benefit of lazy grazing may have become more important, finally (in times of plenty, say) to become more important as a means sexual attraction.
Actually, mp1e can capture from V4L to MPEG-1 in realtime on modest hardware!!! It's awesomely optimized.
xawtv does what you want and is actively maintained. Unfortunately it uses the crappy Xaw widgets for its controls, but hey it's free...
xanim doesn't fully support MPEG-1 - it's not buggy (not that xanim doesn't have bugs in other formats) but just that it only supports MPEG key frames, not intermediate ones.
Try mtv, smpeg, xmovie, LAMP..
If you want decent fullscreen support on a slower speed machine (as you would get in Windows), then you need XFree 4.0 with the Xv extension and a player that supports it. Xv supports shared memory transfer of YUV images (MPEG decoder output) from user space directly to the graphics card memory, and uses the graphics card's hardware YUV-to-RGB conversion and scaling support.
BTW, there's only a few cards (such as Matrox g400) that have Xv driver support yet.
If you don't have Xv support, then second best would be a player like LAMP that supports DGA (direct video memory access under XFree).
xmovie
LAMP
Huh? Are you looking for a (V4L) video capture app, or a media player?
From what I've seen every day stuff costs pretty much the same in Canada as the US, so it's not valid to say $1 US = $1 CAN - you DO have to take the exchange rate into account. That $40 US sweater will cost you $40 US ($60 CAN) in Canada.
Housing costs do seem to be generally cheaper in Canada, as does auto insurance (presumably because you don't sue each other all the time like the dickheads here do), but I still don't think that a 2/3 salary ($70-80K CAN vs $70-80K US) is going to give you have quite the same comfort of lifestyle.
avifile may read divx's, but it certainly doesn't work for all windows video CODECs. Have you ever tried getting it to use one other than those it comes bundled with - I hav't been able to get a single additional one to work - then all fail in different ways.
Still, if you do want to use avifile, aviplay and XMPS are not the best players. Try LAMP or XTheatre instead.
There are better options for MPEG also. SMPEG only works for MPEG-1 (as does mtvp). For MPEG-2, try xmovie, xine, or the VideoLan client.
There's also at least 3 Open Source divx (i.e. MPEG-4) CODEC efforts that I'm aware of - I submitted the story yesterday, but it was rejected.
Isn't there still a large salary difference between what a software engineer can make in the US vs Canada? With a bit of experience it's very easy to make $70-80K+ in the US, or a lot more if you're a contracter. How easy would it be to make the same (say $120K CAN) in Canada? I'm not talking top salaries, but rather what a typical experienced guy can expect...
Agreed, there may be other advantages to living in Canada, but financially it seems a loss.
You talk like they'd be getting something rather than just having less taken away.
Forget tax "cuts" (i.e. adjustments to the current screwed up system), and justify this: Why should a person who earns more than someone else pay more in taxes? Government enforced philanthropy?
Even with a flat $ (forget %) income tax, wealthy people would still be paying WAY more in taxes by way of sales tax.
Tax the rich only makes sense if you're willing to admit it's nothing to do with being fair - it's about socialism.
Got to disagree with you there.
This was a brute force game tree algorithm, so I'd give more credit to the specialized hardware than software.
If a program could beat Kasparov without this sort of exhaustive evaluation, THEN I'd be impressed.
There's not the symmetry between Linux and Windows experience that you seem to imply. Windows was built for the masses, and tries to hide detail from you, but Linux does the reverse. Linux is built by techies for techies - people who happily trade ease-of-use for power and flexibility; people who not only are capable of looking under the hood when things break, but usually actually enjoy doing so! Does every Windows user have the potential to be a Unix administrator (i.e. Linux user)? Nah....
Did you install off a CD-R ?
I initially downloaded 7.1 as an iso image at work and burned it to a CD-R, but it was so flaky I couldn't even install it properly. I ended up buying a mass produced version from Cheapbytes which was fine...
Whatever the reason, if it's a clean install it sounds like something's corrupted.... Is that the only problem you're having?
Excellent!
These are the best racoon pictures I have seen on slashdot today.
Did you upgrade from some earlier version of Linux? Perhaps you're somehow using an earlier version of the dynamic linker rather than the one that came with 7.2?
I just installed 7.1 (not 7.2) and it's got a lot of rough edges. Harddrake segaulted in some CD-ROM detect routine (I installed off CD), Sounddrake failed to detect my sound system, or correctly configure it when I specified everything (sndconfig worked though). The KDE/GNOME menu update/sync stuff fails miserably (best to disable it). The emacs provided has been patched to hardcode Alt=Meta (I downloaded a normal version)...and plenty of other minor inconveniences that would probably be a huge pain for someone new to Linux. It may be a pretty nice distro, but IMO not yet ready for Windows weenies...
Money well spent if you ask me.
Think about it: zero gravity...
That's one toilet you care about.
Ah, but what if it could be a better slashdot? Surely you don't believe it has achieved a unimprovable state of excellence?
There are many things that make slashdot what it is, but I don't know that the details of story selection are really a huge part of that (other than an annoying part such as when rejected submissions turn up days later as "news" or the 101th one-click-patent story gets run).
For my money, the real flavor and value of slashdot comes from the collective personality and knowledge of the posters more than anything else.
I don't see it makes a difference whether /. is Rob's baby or a commercial endeavor - it's a news (for nerds) site, and should make an effort to make sure that the stories are in fact "news" and not unsubstantiated rumours (RH 7 has a zillion bugs).
/. article selection from the submission queue, and have the submission queue instead made available for moderation ("interesting story", "old news", "already appeared", "not true" etc).
/. at a story level of 5, and others with more time on their hands could use lower levels.
What I'd really like to see, which would actually address the above is to get rid of
People who want high quality timely news would view
The old fseek(), ftell() which used a long to represent the file offset are being replaced by fseeko() and ftello(), which use off_t, specifically as part of phasing in Large File Support (LFS). This API is available on Sun (others too, I'm sure) as well as Linux.
In order to enable fseeko/tello, you should compile your code with -D_LARGE_FILESOURCE, which will give you a default (currently 32bit) off_t. If you add -D_FILE_OFFSET_BITS=64, then off_t will be 64 bit, and fseeko/tello will be redefined as their 64 bit cousins. These definitions are part of the LFS standard.
glibc6 already has 64bit support, but of course you also need a new kernel (2.4) to get the >2GB support. AFAIK there's no 2.2.x backport.
BTW Mandrake 7.1 has a buggy stdio.h that doesn't support _LARGE_FILESOURCE (I believe it's been fixed in a more recent version). You can use -D__USE_UNIX98 instead to enable fseeko/tello support.
If we're near saturation point for PC's then we must be super-saturated for stereos, TV's, VCR's, cameras, cars....
It's wonderful the way this stuff lasts forever, always stays in fashios, and magically updates itself to the latest capabilities, isn't it?!
If you're using a temporary list to hold an arbitrary number of things prior to allocating an array to store/access them more efficiently it's useful to know how many elements you have, as it is if you're using one as a queue and want to trigger code based on high/low threshholds, or even if you're waiting for a list to become empty, but want to know how many items are still left... Perhaps more to the point though, a library writer (esp. a basic data structure library) shouldn't make lazy/sloppy assumptions about how it's going to be used.
I agree with you about C++. I think the problem isn't just programmers who don't fully understand some of the more complex features, but also incorrect and incomplete implementations of the lanuage.
I just took another look at SGI's version, but as before find more reasons to stay away than to use it...
You're right that it does specify performance characteristics, but they don't seem that desireable...I noticed that list::size() is listed as being O(N) rather than constant time! Would it really hurt the implementation to require a count++/-- when items are added or deleted? This may seem like a small gripe, but it makes the list class (one of the must useful basic types!) much less useful than it should be - I often use the equivalent size() function of my own list class assuming that it's essentially zero cost.
The other thing that hits me everytime I look at STL is the complexity vs the functionality provided... just take a look at the iterator invalidation semantics of basic_string! Am I meant to remember that stuff? It certainly seems to put an undue burdon on anyone having to maintain code.
If I thought that STL adoption was inevitable, then I might still grumble but start using it anyway, but considering how long it's been out and the current level of adoption, I think maybe that it has risen/sunk to it's own level, and will never be as ubiquitous as it could have been...
I've never seen any performance guarantees for the STL. AFAIK any implementation is free to implement the standard in any way they choose, and I'd be very surprised if they all (for example) chose to implement hash tables the same way. OTOH my hashtable uses insert-at-start chained overflow, so I know precisely what the performance characteristics are.
;-)
I don't know why you'd think my code has bugs or a hard to learn interface. I've been programming since probably before you were born, so I think I've got the hang of it by now!
Your other points are equally dubious...
Which implementation of the STL do you claim is bug free - SGI's, HP's, GNU's? Whichever you use? Them all? The fact is that aspects of the STL String class can be formally proved to be unimplementable without bugs, which is why the Rope class is preferred.
STL well understood by all professional programmers? Hardly. In a Sun/C++ environment people are much more likely to have used Rogue Wave's classes than STL.
AFAIK (certainly at companies I've worked at), STL adoption is far from widespread. As I pointed out in another reply, even a well-designed modern C++ library such as Qt doesn't use it. I don't think GTK-- (the C++ GTK+ interface) does either. Maybe I'm not the only one to find it of limited value...
I'd agree with you if it wern't for the fact that I've yet to come across a library that used STL as part of it's interface! In fact, the only C++ (vs C) library I'm using right now is Qt which implements it's own datastructure classes!
Are there any/many libraries that you're aware of that do operate on STL types?