It can be a boon or a curse, depending on how much you really know about the packages you are installing. In theory, you get a pretty clean, smooth system as you only install the bits you specify, and you can hand tune the compiles and dependencies such that you don't have to install unwanted bits just to get what you want to work, and it will do all this without breaking the package manager (i.e. if you go from a non-RPM in redhat, those files are now kind of rogue).
Unfortunately, there are pitfalls to be a ware of. One is that the occasional package is overlooked in terms of updates. For example, xmame is outdated in grimoire, so I manually edit the grimiore on every update to make sure it doesn't overwrite my more recent copy witha n older copy.
Another thing is that by rolling your own custom configuration, you are really exploring brand new territory. No one has tested that particular combination of packages to see if there are any issues, and by mixing the latest and greatest of everything, invariably you get some mismatches that produce unpleasant results if you don't know what to be careful of.
Also, the compilation of some packages on some hardware, particularly XFree. For example, if you have a Voodoo3, you need to get glide3 separate first. Even then you have to use tdfx for DRI rather than TdfxDRI or whatever is offered in the menu, as the ifdefs don't work in the.cf files.
As to performance, yes it is highly optimized and you can omit debug symbols and such. However, it uses 2.95.3, which results in a more stable distro, but in a way counterbalances the advantages of compiling yourself, as the 2.95.3 doesn't optimize for x86 nearly as well as gcc 3...
I can bite on this one:) In 1999, I was a Unix administrator for a combination Sun3/Sun4 systems. The Sun3 systems were from about the same era as that Mac LC, and had a m68k processor (Sun3 were before Sun started their own processor line, which they began with the Sun4 system. Ahhh, the huge VME bus systems, a huge board of memory was 8 megs, a 150 pound hardwdrive was 500 megs... Oh, and those write protect rings, so colorful and fun... Of source the Sun3 systems didn't enjoy the new fangled equipment that the Sun4s did, they were all made into diskless X terminals. Most of the Sun4s were diskless as well, netbooting and loading everything off of nfs, but they did their own processing, And then there was the speeddemon, the Sparc 1+. Then they had to ruin all the fun and get donated HP 712 and similar HP-UX systems that were only a few years old, as opposed to 12-14 years old. No more soldering to save malfunctioning VME boards, sigh...
It was really kinda neat and worked well in the limited cpacity it could...
But it had gotten right in architecture design, they more than made up for in terms of application and hardware support.
I know, the software is chicken and egg syndrome for a proprietary operating system, but they needed something to appeal. They at least had a focus, multimedia applications, but they didn't even have a decent MPEG-1 decoder, only a really slower, really low quality decoder, and that was, unfortunately, perhaps the best Be ever got with a widespread media format/codec. If they had given away the platform from the start with the Development tools, they might have garnered enough application support to carry them further. It seems to me after free.be.com started doing its thing, that BeBits started to pick up in development efforts. If they had been around before Linux had gotten a lot of decent multimedia and desktop support, they might have stood a better chance.
As far as hardware, for a multimedia OS, the video card drivers were always crap. Rarely did they support stuff like YUV overlays, and they expected to be a good multimedia OS? Sorry, but I don't think so.
The reality is now you have MS for most all desktop users, Mac for the anti-establishment, but non-techincal people with money to throw at overpriced hardware, and Linux for geeks like me, which now has decent multimedia playback and desktop software. Not good for content creation or gaming (but could be with the right applications..), but quite suitable for so much else...
Ok, so they design and market a DVD drive that thoroughly prevents CSSed data to be read except under "endorsed" situations, or something like that. They take it a step further, and make DVD drives that don't use this scheme illegal to sell. Now, who is going to knock down my door, rip out my good old 2x dvd drive and force me to buy this new thing?
Will my current computer become illegal, would a law be forcing me to shell out over a thousand dollars to stay legal?
Since MS has patents on DRM OS, would MS products suddenly become the only legal OSes (government enforced monopoly). How does Sun, Apple, RedHat, and the many many companies who has an infrastructure dependent on non-MS software feel about having their products made illegal, or being forced to spend millions to migrate infrastructures to MS-only?
Without new media, no one can force new hardware on consumers, therefore the existing hardware will be accessible to pirates if they so desire. You start releasing something new so soon after the widespread acceptance of DVD and completely drop DVD technology, consumers will be royally pissed. Suddenly making tons of software illegal (especially open-source software becomes impossible, someone could easily disable the DRM bits) would also piss off companies and individuals who want to operate legally, but would have little impact on those who could care less about copyright law (already illegal, why pay attention to a new law?).
So the SSSCA basically penalizes the innocent and has essentially no impact on piracy when you think about it....
For example, the studentdev.org thing they set up. Part of those programs was that students would get free copies of Visual Studio and Operating systems, to keep the students interested in developing for MS.
Lately, I haven't seen this so much, but I have seen the MSDN Academic Alliance, where they sell a massive license to a school for relatively cheap, and then allow all students in that school/deparetment to download all kinds of software for free legally. Included is stuff like Win2k Advanced server (which has a sticker price of nearly 4,000 dollars), and tons of applications. They will put the prices on the OS and development tools as low as they have to, just to keep corporations buying into their products.
http://www.freeswan.org/freeswan_trees/freeswan-1. 95/doc/interop.html contains some links, right now the tripod exceeded bandwidth, and that is the one with Windows interop. instructions, but I have seen it and it looks pretty solid.
But then, how do you ensure the client is using approved software if you are using a standard like IPSEC? I know, corporate policy, but if people are at home, they might try more exotic things... In any event, clients configured like this are a good way to make IPSEC *better* for telecommuting, but the safest bet is to not have full network transparency, but instead only have selected services that telecommuters need and allow only those in your preferred method of access..
To get an idea of the convoluted navigation: First near bottom of screen clcik on "Previous Player Versions" Then the tiny "Realplayer 8 Basi is our free player" link. Then select UNIX to get new form, then you must select a Linux 2.x version to get the right screen next (rpm or tar, doesn't matter). Then ignore the download links and scroll down below item number 5.. There you are.... To shortcut to the Unix form, here is url: http://proforma.real.com/real/player/unix/un ix.htm l
Of course, ppp over ssh implies a full IP tunnel using ppp with ssh underneath, IP in TCP encapsulation, essentially. You get full IP functionality this way, though the architecture is horribly flawed (TCP connections run with TCP somewhere underneath, very bad when packets get loss and two layers start doing recovery).
Now ssh without ppp on top supports only TCP tunnels, I'll assume that is what you are talking about. A statement that says you need to use IP, but you only get TCP sounds really goofy, since TCP rides on top of IP, phrasing it with the protocols you need (i.e. udp, icmp, etc) would have made the post more sensible (that and omitting ppp...). If I heard someone make the statement you just made I wouldn't trust them with firewall configuration either...
When dealing with internal systems, you can enforce all kinds of policies about virus software, etc. You can keep it relatively boxed. With telecommuting, the clients not only have relaxed restrictions, but also are vulnerable while connected to the internet to the sort of attacks firewalls are meant to keep out. Normally, this wouldn't be too bad, but with a full tunnel, that machine will probably contain sensitive information itself and, for the duration of the connection, gives full access to a corporate network if compromised.
L2TPd for linux exists, separate from FreeS/WAN. Though commonly coupled with IPSEC, L2TP is separate. I have heard reports that FreeS/WAN+l2tpd can be used to provide the functionality you describe to have a pretty solid VPN with FreeS/WAN and Windows ends.
http://www.marko.net/l2tp/
A bit dated, but reportedly still functional...
Now as far as getting connectivity to Cisco with Windows with tunneling, I have no idea, never tried...
What is so much better about Windows RealPlayer 8 than the linux version? Only difference off hand is that under Windows they support Hardware overlays for faster colorspace conversion and good scaling, and this improvement is lost when you have to use wine which forces everything to software mode anyway. If anything, I would reason the Windows version would be much slower under wine.
If you want an improved version, you can chop your way through real's site to find a realone beta for linux, which supports XVideo for playback. Of course, it is flaky, but if you have RealOne for primary playback and Real8 as fallback for when RealOne craps out, it is quite usable...
Of course, ppp over ssh is a bad thing, ugly and bad. For most traffic, you have this topography: TCP over IP over ppp over ssh over TCP over IP, etc...
Note the fact that we have TCP over TCP, which is bad, very very bad. If a packet gets lost, we have two layers doing the same thing to restore a connection and things can get stalled out quickly....
ssh's built in tcp tunneling suffices for most remote access applications. For a true VPN, IPSEC is the only good way to go. Other things like CIPE certainly work better than ppp aver ssh, but still lack in certain features things that IPSEC does. Then again, if you have to build a VPN where you need to modify packets in transit (i.e. NAT), CIPE is a viable alternative if you don't mind that packets could be mangled by more than just the NAT gateways and CIPE wouldn't care, but I personally want to ensure the highest security with IPSEC...
Of course, to play realmedia files maybe you should try realplayer? Just a thought... Thought the site is horrible to navigate, you can find it. Basically, you have to request the older version, then select unix, then poke around enough and you can even find a RealOne beta for linux, which supports the XVideo extension for hardware scaling and colorspace conversion.
For Windows Media, try avifile, PythonTheater, xine, or mplayer. Though it is good they are working towards this stuff, Windows Media Player through wine is inelegant, since the overhead imposed by wine and the lack of XVideo support makes media playback bad. Only reason to tolerate QuickTime through wine is because there is no other option for Sorenson encoded media...
Already we have the library avifile for managing nearly any WMP format, as well as xine and mplayer. Quicktime was important because no one has gotten Sorenson to work in any form under linux. Windows Media not only plays using avifile and such, but keeps the wine stuff at the lowest level possible, even replacing win32 codecs with native ones when possible (i.e. vorbis, mp3, divx, etc...). This means for one thing performance is tolerable. For another, at the higher levels you are guaranteed to do more sophisticated things with the output. Foremost of these is making use of hardware overlay surfaces in different color formats (YUV overlays) providing hardware colorspace conversion and smooth scaling, improving both quality and performance. Using WMP through wine means that not only is much more of the code done in inefficient win32-in-linux mode, it means there is no capacity for native codecs and that all colorspace conversion, scaling, and filtering must be done in software, prohibitively slow.
Right, but I was saying that IPSEC is not only not a magic bullet (that is to be expected) but companies outright misuse the technology without any serious thought. They invest tons in making sure they have tight firewalls and policies that prohibit people from hooking up modems to the outside world (internet without firewall), and yet repeat the mistake in a different form time and time again. It would be nice to establish trusted connections to telecommuters, but it just simply can never be secure enough (well, maybe if the telecommuter is the same person who designed the corporate security and takes home security equally seriously, but not worth finding out).
IPSEC "clients" for Windows: PGPnet- commercial and free versions. Free version doesn't do complicated routing stuff Windows 2000 and newer have built in IPSEC capabilities.
Both these methods can interact with CISCO, OpenBSD, and FreeS/WAN.
IPSEC is the best shot you have at a cross-platform standard.
Better solution than, say, ppp over ssh (a really dumb hack), but not better than IPSEC for most all applications.
IPSEC also does not run TCP over TCP, it uses udp for isakmp, and data is transmitted through custom protocols (numbers 50 and/or 51), *not* through TCP.
Another thing about IPSEC that works better than CIPE is that IPSEC more strongly authenticates the machine at the other end. This is why NAT breaks, because unlike CIPE, IPSEC works to ensure the packet has passed unmodified since leaving a known trusted host, and the very nature of NAT prevents this. Solution is simple, move the IPSEC gateway to either the NAT system or beyond. Though it is being pushed in many circles as a good solution for telecommuting, it really was never designed for that and that usage really spits in the face of firewalls.
Finally, CIPE lacks compatibility. Sure you can configure windows and linux boxes and maybe other platforms, but just try to connect to, say a CISCO router....
CIPE is a hack that creates more problems than it solves in the long run. PPP over ssh is worse, but a dumb idea, set up tunnels for specific tcp services that you need, more overhead, but security is better (not perfect, but better). For connecting networks together, a good architect can piece together an IPSEC solution that guarantees identity at other end of the pipe... CIPE offers the gaping whole that IPSEC can while not offering enough identification. So ssh or IPSEC remains the best solution, depending on the problem.
IPSEC is wonderful, but many businesses don't think things through and use it for telecommuting. Why is this bad? Well, the way this works is that someone connects to the VPN system and gets a full tunnel that allows the authorized client to behave on the internal network as if it was actually there, bypassing the firewall. The problem here is pretty obvious. The client machine is not protected by a firewall,a nd so if the client is compromised, an attacker has a clear path straight past the firewall. So the effectiveness of the firewall is greatly reduced.
Now if you don't have a firewall protectecting the network, this won't hurt, but if you do, then a solution like ssh is somewhat more secure, as you only set up the tunnels you absolutely need to very specific hosts. While there is still a risk, it is greatly reduced and strikes a good balance between usability and security.
What IPSEC *is* good for is seamlessly connecting sites together without really expensive dedicated lines securely. While it makes no guarantee as to bandwidht or availability, it does provide almost the same level of security. If a company can't afford lines to sites but still wants to expand, IPSEC is ideal. I use it to connect my home private network to a friends home private network. The key here is that not only do you have to trust the clients whose keys you permit to connect, but you must also trust that the administrator of that client machine or network is sufficiently competent to keep his network secure, as the security of the two networks is tied a lot more closely together...
Just FYI, but Win2k and newer (at least) include native IPSEC support that can interoperate with FreeS/WAN and such. Other systems, well, they are intended for home use that doesn't need that functionality..
MIDI can sound really good and offer very nice compression, *if* you have a good soundfont.
http://www.personalcopy.com/ has some great ones, my personal favorite being a 56 MB soundfont which together with either timidity or an appropriate soundcard sounds fantastic. Still not possible to accurately reproduce exactly what the creator heard when he put the piece together (unless you are sure you use the same soundfont), but it still sounds great.
Re:GNOME vs KDE for the newbie
on
GNOME 2.0 Beta
·
· Score: 2
Nothin wrong with Desktop mode, just saying gmc had it too... And actually, I kinda prefer the Desktop being treated as "special" as it is in ROX, as it can only contain links to files/locations and links themselves. Guess it is kind of a moot point in Linux, but especially in windows it is bad that the desktop can hold files. Under windows if you have roaming profiles, login must wait for all files to download to local drive (and enough local space must be free for the profile). Since the desktop is in the profile, this can make things really slow for people who just dump everything onto the desktop. I guess on Linux it becomes more of a stylistic issue since data over nfs is laoded as needed...
Re:GNOME vs KDE for the newbie
on
GNOME 2.0 Beta
·
· Score: 2
It already is (for GNU tar), though not as cleanly as compress/gzip, and no where near universal. The default for modern tar builds straight from gnu.org is to use -y. Early versions of tar with bzip2 used -I, and a lot of places currently use -j, I think because of some command conflict with I. If you use, say slackware or sorcerer, you have the -y option. Now combining it with the z option might be possible for decompressing, but for compressing you really need separate options, as bzip2drastically does better for text, but for non-text data is comparable to gzip but remains dog slow..
Re:GNOME vs KDE for the newbie
on
GNOME 2.0 Beta
·
· Score: 2
but gmc *does* have a desktop mode, duh...
That aside, anyone who would claim that gmc offers similar performance to rox needs to try both on a pentium 166 or so and then get back to me...
Feature-wise, I like ROX a hell of a lot better. Many more hooks for keybopard and shell like cpaabilities than gmc. It doesn't have as much eye-candy as Nautilus, but icons are still well done. The one thing I do kinda miss occasionally is the tree view for directory navigation, but the respnsiveness and the well done keyboard interaction make it worthwhile.
Slashdot Mirror
It can be a boon or a curse, depending on how much you really know about the packages you are installing. In theory, you get a pretty clean, smooth system as you only install the bits you specify, and you can hand tune the compiles and dependencies such that you don't have to install unwanted bits just to get what you want to work, and it will do all this without breaking the package manager (i.e. if you go from a non-RPM in redhat, those files are now kind of rogue).
.cf files.
Unfortunately, there are pitfalls to be a ware of. One is that the occasional package is overlooked in terms of updates. For example, xmame is outdated in grimoire, so I manually edit the grimiore on every update to make sure it doesn't overwrite my more recent copy witha n older copy.
Another thing is that by rolling your own custom configuration, you are really exploring brand new territory. No one has tested that particular combination of packages to see if there are any issues, and by mixing the latest and greatest of everything, invariably you get some mismatches that produce unpleasant results if you don't know what to be careful of.
Also, the compilation of some packages on some hardware, particularly XFree. For example, if you have a Voodoo3, you need to get glide3 separate first. Even then you have to use tdfx for DRI rather than TdfxDRI or whatever is offered in the menu, as the ifdefs don't work in the
As to performance, yes it is highly optimized and you can omit debug symbols and such. However, it uses 2.95.3, which results in a more stable distro, but in a way counterbalances the advantages of compiling yourself, as the 2.95.3 doesn't optimize for x86 nearly as well as gcc 3...
I can bite on this one :) In 1999, I was a Unix administrator for a combination Sun3/Sun4 systems. The Sun3 systems were from about the same era as that Mac LC, and had a m68k processor (Sun3 were before Sun started their own processor line, which they began with the Sun4 system. Ahhh, the huge VME bus systems, a huge board of memory was 8 megs, a 150 pound hardwdrive was 500 megs... Oh, and those write protect rings, so colorful and fun... Of source the Sun3 systems didn't enjoy the new fangled equipment that the Sun4s did, they were all made into diskless X terminals. Most of the Sun4s were diskless as well, netbooting and loading everything off of nfs, but they did their own processing, And then there was the speeddemon, the Sparc 1+. Then they had to ruin all the fun and get donated HP 712 and similar HP-UX systems that were only a few years old, as opposed to 12-14 years old. No more soldering to save malfunctioning VME boards, sigh...
It was really kinda neat and worked well in the limited cpacity it could...
But it had gotten right in architecture design, they more than made up for in terms of application and hardware support.
I know, the software is chicken and egg syndrome for a proprietary operating system, but they needed something to appeal. They at least had a focus, multimedia applications, but they didn't even have a decent MPEG-1 decoder, only a really slower, really low quality decoder, and that was, unfortunately, perhaps the best Be ever got with a widespread media format/codec. If they had given away the platform from the start with the Development tools, they might have garnered enough application support to carry them further. It seems to me after free.be.com started doing its thing, that BeBits started to pick up in development efforts. If they had been around before Linux had gotten a lot of decent multimedia and desktop support, they might have stood a better chance.
As far as hardware, for a multimedia OS, the video card drivers were always crap. Rarely did they support stuff like YUV overlays, and they expected to be a good multimedia OS? Sorry, but I don't think so.
The reality is now you have MS for most all desktop users, Mac for the anti-establishment, but non-techincal people with money to throw at overpriced hardware, and Linux for geeks like me, which now has decent multimedia playback and desktop software. Not good for content creation or gaming (but could be with the right applications..), but quite suitable for so much else...
Ok, so they design and market a DVD drive that thoroughly prevents CSSed data to be read except under "endorsed" situations, or something like that. They take it a step further, and make DVD drives that don't use this scheme illegal to sell. Now, who is going to knock down my door, rip out my good old 2x dvd drive and force me to buy this new thing?
Will my current computer become illegal, would a law be forcing me to shell out over a thousand dollars to stay legal?
Since MS has patents on DRM OS, would MS products suddenly become the only legal OSes (government enforced monopoly). How does Sun, Apple, RedHat, and the many many companies who has an infrastructure dependent on non-MS software feel about having their products made illegal, or being forced to spend millions to migrate infrastructures to MS-only?
Without new media, no one can force new hardware on consumers, therefore the existing hardware will be accessible to pirates if they so desire. You start releasing something new so soon after the widespread acceptance of DVD and completely drop DVD technology, consumers will be royally pissed. Suddenly making tons of software illegal (especially open-source software becomes impossible, someone could easily disable the DRM bits) would also piss off companies and individuals who want to operate legally, but would have little impact on those who could care less about copyright law (already illegal, why pay attention to a new law?).
So the SSSCA basically penalizes the innocent and has essentially no impact on piracy when you think about it....
For example, the studentdev.org thing they set up. Part of those programs was that students would get free copies of Visual Studio and Operating systems, to keep the students interested in developing for MS.
Lately, I haven't seen this so much, but I have seen the MSDN Academic Alliance, where they sell a massive license to a school for relatively cheap, and then allow all students in that school/deparetment to download all kinds of software for free legally. Included is stuff like Win2k Advanced server (which has a sticker price of nearly 4,000 dollars), and tons of applications. They will put the prices on the OS and development tools as low as they have to, just to keep corporations buying into their products.
http://www.freeswan.org/freeswan_trees/freeswan-1. 95/doc/interop.html
contains some links, right now the tripod exceeded bandwidth, and that is the one with Windows interop. instructions, but I have seen it and it looks pretty solid.
But then, how do you ensure the client is using approved software if you are using a standard like IPSEC? I know, corporate policy, but if people are at home, they might try more exotic things... In any event, clients configured like this are a good way to make IPSEC *better* for telecommuting, but the safest bet is to not have full network transparency, but instead only have selected services that telecommuters need and allow only those in your preferred method of access..
To get an idea of the convoluted navigation:n ix.htm l
First near bottom of screen clcik on "Previous Player Versions"
Then the tiny "Realplayer 8 Basi is our free player" link. Then select UNIX to get new form, then you must select a Linux 2.x version to get the right screen next (rpm or tar, doesn't matter). Then ignore the download links and scroll down below item number 5.. There you are....
To shortcut to the Unix form, here is url:
http://proforma.real.com/real/player/unix/u
Of course, ppp over ssh implies a full IP tunnel using ppp with ssh underneath, IP in TCP encapsulation, essentially. You get full IP functionality this way, though the architecture is horribly flawed (TCP connections run with TCP somewhere underneath, very bad when packets get loss and two layers start doing recovery).
Now ssh without ppp on top supports only TCP tunnels, I'll assume that is what you are talking about. A statement that says you need to use IP, but you only get TCP sounds really goofy, since TCP rides on top of IP, phrasing it with the protocols you need (i.e. udp, icmp, etc) would have made the post more sensible (that and omitting ppp...). If I heard someone make the statement you just made I wouldn't trust them with firewall configuration either...
When dealing with internal systems, you can enforce all kinds of policies about virus software, etc. You can keep it relatively boxed. With telecommuting, the clients not only have relaxed restrictions, but also are vulnerable while connected to the internet to the sort of attacks firewalls are meant to keep out. Normally, this wouldn't be too bad, but with a full tunnel, that machine will probably contain sensitive information itself and, for the duration of the connection, gives full access to a corporate network if compromised.
L2TPd for linux exists, separate from FreeS/WAN. Though commonly coupled with IPSEC, L2TP is separate. I have heard reports that FreeS/WAN+l2tpd can be used to provide the functionality you describe to have a pretty solid VPN with FreeS/WAN and Windows ends.
http://www.marko.net/l2tp/
A bit dated, but reportedly still functional...
Now as far as getting connectivity to Cisco with Windows with tunneling, I have no idea, never tried...
What is so much better about Windows RealPlayer 8 than the linux version? Only difference off hand is that under Windows they support Hardware overlays for faster colorspace conversion and good scaling, and this improvement is lost when you have to use wine which forces everything to software mode anyway. If anything, I would reason the Windows version would be much slower under wine.
If you want an improved version, you can chop your way through real's site to find a realone beta for linux, which supports XVideo for playback. Of course, it is flaky, but if you have RealOne for primary playback and Real8 as fallback for when RealOne craps out, it is quite usable...
Of course, ppp over ssh is a bad thing, ugly and bad. For most traffic, you have this topography:
TCP over IP over ppp over ssh over TCP over IP, etc...
Note the fact that we have TCP over TCP, which is bad, very very bad. If a packet gets lost, we have two layers doing the same thing to restore a connection and things can get stalled out quickly....
ssh's built in tcp tunneling suffices for most remote access applications. For a true VPN, IPSEC is the only good way to go. Other things like CIPE certainly work better than ppp aver ssh, but still lack in certain features things that IPSEC does. Then again, if you have to build a VPN where you need to modify packets in transit (i.e. NAT), CIPE is a viable alternative if you don't mind that packets could be mangled by more than just the NAT gateways and CIPE wouldn't care, but I personally want to ensure the highest security with IPSEC...
Of course, to play realmedia files maybe you should try realplayer? Just a thought... Thought the site is horrible to navigate, you can find it. Basically, you have to request the older version, then select unix, then poke around enough and you can even find a RealOne beta for linux, which supports the XVideo extension for hardware scaling and colorspace conversion.
For Windows Media, try avifile, PythonTheater, xine, or mplayer. Though it is good they are working towards this stuff, Windows Media Player through wine is inelegant, since the overhead imposed by wine and the lack of XVideo support makes media playback bad. Only reason to tolerate QuickTime through wine is because there is no other option for Sorenson encoded media...
Already we have the library avifile for managing nearly any WMP format, as well as xine and mplayer. Quicktime was important because no one has gotten Sorenson to work in any form under linux. Windows Media not only plays using avifile and such, but keeps the wine stuff at the lowest level possible, even replacing win32 codecs with native ones when possible (i.e. vorbis, mp3, divx, etc...). This means for one thing performance is tolerable. For another, at the higher levels you are guaranteed to do more sophisticated things with the output. Foremost of these is making use of hardware overlay surfaces in different color formats (YUV overlays) providing hardware colorspace conversion and smooth scaling, improving both quality and performance. Using WMP through wine means that not only is much more of the code done in inefficient win32-in-linux mode, it means there is no capacity for native codecs and that all colorspace conversion, scaling, and filtering must be done in software, prohibitively slow.
Right, but I was saying that IPSEC is not only not a magic bullet (that is to be expected) but companies outright misuse the technology without any serious thought. They invest tons in making sure they have tight firewalls and policies that prohibit people from hooking up modems to the outside world (internet without firewall), and yet repeat the mistake in a different form time and time again. It would be nice to establish trusted connections to telecommuters, but it just simply can never be secure enough (well, maybe if the telecommuter is the same person who designed the corporate security and takes home security equally seriously, but not worth finding out).
IPSEC "clients" for Windows:
PGPnet- commercial and free versions. Free version doesn't do complicated routing stuff
Windows 2000 and newer have built in IPSEC capabilities.
Both these methods can interact with CISCO, OpenBSD, and FreeS/WAN.
IPSEC is the best shot you have at a cross-platform standard.
Better solution than, say, ppp over ssh (a really dumb hack), but not better than IPSEC for most all applications.
IPSEC also does not run TCP over TCP, it uses udp for isakmp, and data is transmitted through custom protocols (numbers 50 and/or 51), *not* through TCP.
Another thing about IPSEC that works better than CIPE is that IPSEC more strongly authenticates the machine at the other end. This is why NAT breaks, because unlike CIPE, IPSEC works to ensure the packet has passed unmodified since leaving a known trusted host, and the very nature of NAT prevents this. Solution is simple, move the IPSEC gateway to either the NAT system or beyond. Though it is being pushed in many circles as a good solution for telecommuting, it really was never designed for that and that usage really spits in the face of firewalls.
Finally, CIPE lacks compatibility. Sure you can configure windows and linux boxes and maybe other platforms, but just try to connect to, say a CISCO router....
CIPE is a hack that creates more problems than it solves in the long run. PPP over ssh is worse, but a dumb idea, set up tunnels for specific tcp services that you need, more overhead, but security is better (not perfect, but better). For connecting networks together, a good architect can piece together an IPSEC solution that guarantees identity at other end of the pipe... CIPE offers the gaping whole that IPSEC can while not offering enough identification. So ssh or IPSEC remains the best solution, depending on the problem.
IPSEC is wonderful, but many businesses don't think things through and use it for telecommuting. Why is this bad? Well, the way this works is that someone connects to the VPN system and gets a full tunnel that allows the authorized client to behave on the internal network as if it was actually there, bypassing the firewall. The problem here is pretty obvious. The client machine is not protected by a firewall,a nd so if the client is compromised, an attacker has a clear path straight past the firewall. So the effectiveness of the firewall is greatly reduced.
Now if you don't have a firewall protectecting the network, this won't hurt, but if you do, then a solution like ssh is somewhat more secure, as you only set up the tunnels you absolutely need to very specific hosts. While there is still a risk, it is greatly reduced and strikes a good balance between usability and security.
What IPSEC *is* good for is seamlessly connecting sites together without really expensive dedicated lines securely. While it makes no guarantee as to bandwidht or availability, it does provide almost the same level of security. If a company can't afford lines to sites but still wants to expand, IPSEC is ideal. I use it to connect my home private network to a friends home private network. The key here is that not only do you have to trust the clients whose keys you permit to connect, but you must also trust that the administrator of that client machine or network is sufficiently competent to keep his network secure, as the security of the two networks is tied a lot more closely together...
Just FYI, but Win2k and newer (at least) include native IPSEC support that can interoperate with FreeS/WAN and such. Other systems, well, they are intended for home use that doesn't need that functionality..
But look at the benefits he was collecting, over 400 a week.... He'd lose money compared with unemployment by going to McDonald's.
MIDI can sound really good and offer very nice compression, *if* you have a good soundfont.
http://www.personalcopy.com/ has some great ones, my personal favorite being a 56 MB soundfont which together with either timidity or an appropriate soundcard sounds fantastic. Still not possible to accurately reproduce exactly what the creator heard when he put the piece together (unless you are sure you use the same soundfont), but it still sounds great.
Nothin wrong with Desktop mode, just saying gmc had it too... And actually, I kinda prefer the Desktop being treated as "special" as it is in ROX, as it can only contain links to files/locations and links themselves. Guess it is kind of a moot point in Linux, but especially in windows it is bad that the desktop can hold files. Under windows if you have roaming profiles, login must wait for all files to download to local drive (and enough local space must be free for the profile). Since the desktop is in the profile, this can make things really slow for people who just dump everything onto the desktop. I guess on Linux it becomes more of a stylistic issue since data over nfs is laoded as needed...
It already is (for GNU tar), though not as cleanly as compress/gzip, and no where near universal. The default for modern tar builds straight from gnu.org is to use -y. Early versions of tar with bzip2 used -I, and a lot of places currently use -j, I think because of some command conflict with I. If you use, say slackware or sorcerer, you have the -y option. Now combining it with the z option might be possible for decompressing, but for compressing you really need separate options, as bzip2drastically does better for text, but for non-text data is comparable to gzip but remains dog slow..
but gmc *does* have a desktop mode, duh...
That aside, anyone who would claim that gmc offers similar performance to rox needs to try both on a pentium 166 or so and then get back to me...
Feature-wise, I like ROX a hell of a lot better. Many more hooks for keybopard and shell like cpaabilities than gmc. It doesn't have as much eye-candy as Nautilus, but icons are still well done. The one thing I do kinda miss occasionally is the tree view for directory navigation, but the respnsiveness and the well done keyboard interaction make it worthwhile.