I want to know WTF Cox is talking about when he says that "The moment Fedora includes non-free stuff it becomes a problem for all the people who redistribute and respin it".
He is referring to the possibility of licensing proprietary formats, like MP3, which has been discussed within Red Hat and Fedora before. Basically, the Red Hat legal department is of the opinion that if Fedora were to distribute MP3 (or other proprietary codecs) support, then Red Hat could get in trouble. Red Hat has more than enough money to purchase a license for MP3, and would probably be willing to do so even for Fedora, which of course they do not make money off of. But the issue is that they cannot purchase a license that would also apply to redistributors. The people at Fedora have decided that this is a sacrifice they are not willing to make -- they want Fedora to be truly free, and fully redistributable.
With quantum encryption you cannot conduct a meaningful MITM attack. This is called the observer effect, and is a very well known and studied phenomenon of quantum mechanics.
The diversity of packaging formats is definitely a nonissue, because EVERYONE has the source code. Any software that is even moderately popular will be packaged by volunteers. If I need some software that isn't already packaged for me, I grab the source code and compile it. If it's something I plan on sharing with other people, I'll write a spec file and distribute the RPM I build.
I understand that it would perhaps be more optimal if there was a single package format, but that just isn't going to happen. Debian based distros have an enormous time investment in the.deb format, RPM distros have a huge investment in the.rpm format. Likewise for Gentoo, Arch, Slack, and all the other distros with their own formats. There are legitimate reasons for sticking to native formats because of distributions' build infrastructures and installation backends. As long as the source code is available, everyone will be able to install your software, and everyone will be able to use the format of their preference.
I am far from an RPM guru... but I have written a few in my day. Basically the way that an RPM works is you write a spec file which is just a script that tells RPM what actions to perform to install the actual binary. For example, put this file here, change its permissions, restart the running daemon associated with this package, etc. AFAIK the set of commands that you can give to RPM is limited, and I believe that you are not able to tell it to do things like load kernel modules. So sure, if you install an untrusted RPM it can do all kinds of nasty things like clobber your files, but there are limitations to what RPM can do. If you're really paranoid you can also run rpm with SELinux, which obviously has no analog in the Windows world.
Y'know, I imagine stuff like this would be nice to speed up the rendering farms in movie studios. Either make 'm pay for the access or give every contributor with enough cycles a free ticket;).
This only works in a LAN. Every single frame of a modern movie requires gigabytes of texture data etc. etc... It's not something you can send over the Internet.
Not to mention I'm sure they'd be thrilled to have basically the entire movie contents floating around the Internet on random people's computers.
This is a result of Gauss' law, which is a standard result in vector calculus. This is a mathematical proof about continuously differentiable vector fields. If you took vector calculus in college you probably proved it. For the potential to not be differentiable would be _really_ degenerate case, which IIRC you just assume doesn't happen because there are standard formulas for different potentials (e.g. electric potential, gravitational potential) and all of them are well behaved.
Well, he got it working following some instructions for Evolution 2.4, but sadly, while Evolution could display a list of public folders, the 'Subscribe' and 'Unsubscribe' buttons never appear in the dialog, probably due to a bug.
The buttons didn't appear because you're supposed to check the fucking boxes. What kind of shitty UI has check boxes and buttons on the side to check and uncheck the boxes? Checking the boxes is the first thing that anyone who is even mildly computer literate would have tried, so I'm not sure what the problem way. Sure, the picture on the Novell website was a little out of date, but since this is the UI model used in every other Gnome application this should have been a no brainer.
Two reasons: 1) PDF can embed fonts 2) PDF can embed vector graphics natively.
This is a big deal to me. I am a university student studying math. Aside from the obvious reasons that Microsoft doesn't have any compelling (math) typesetting products, there is simply no way that I could create a paper in Word and be able to send it to you and reasonably expect you to be able to read it. You simply don't have the correct fonts/symbols installed on your computer. And if I have some figures or diagrams in the document, I don't want them in some crappy raster image format. I want them in a vector format. Sure, there's no reason that Microsoft couldn't create a vector image format (or adopt something like SVG), but since Postscript (and by association, PDF) has had this capability for twenty years already there simply isn't any reason to.
Again, there's no reason that Microsoft can't create a competing file format that incorporates vector drawing and embedded fonts. But PDF is good, it is a standard, it is well known, etc. It has very important features that are lacking in the Office file formats (and the reverse is true, but that's not the point), and it simply doesn't make a whole lot of sense to try to incorporate these features in to Office.
OpenOffice.org is, in my opinion, the weakest part of the free software desktop experience. It is huge and bloated. It takes 100 MB - 200 MB to install (depending on your operating system), which is way more than it should. It doesn't use any platform's native graphical toolkit. Fonts look like crap in it. Etc, etc.
Honestly, I think that Abiword is orders of magnitude better -- not just in the obvious areas of size and memory footprint, but also in terms of the UI. It looks great in Gnome, and runs on Windows too (and it has a grammar checker!). I'm not a KDE user, but KWord also looks better than OO.o
I don't understand the fixation that people have with Open Office. It's slow. It looks bad. It retains all the things you hated about MS Office. The only things that it has going for it is that it has the most faithful.doc import of any open source office tool, and that it has the best ODT support at the moment. But the day that OO.o dies will be a happy day in my book.
I am a math major (although I don't study prime numbers). This is totally, utterly useless, in a practical sense. Well, it might be useful in the field of CS, although I don't know enough about these project to know if any novel algorithms were used. It is sort of interesting though, because the twin prime conjecture (i.e. the statement that there are an infinite number of such pairs) is still unproven, so it's kind of cool to be able to say "Look, we found another pair!"
(On a side note, I don't know of any mathematicians who doubt the validity of the twin prime conjecture. If you proved that the conjecture was false, then you'd be really famous.)
My understanding is that, among other things, a lot of (poorly written) software is written assuming unrestricted access to the registry, which is why you can't just install and run it locally in Windows.
Yes, it is true that there is a "User Agent" field in the bit torrent protocol, but of course this is easy to modify. My favorite client has a bug in it that has caused it to be banned from some private trackers. Since this was hurting me on some files that I download, I modified the user agent string to cause the client to identify itself as uTorrent 1.6. Problem solved!
I think that the user agent field is fixed width, meaning that even if you don't have access to the source code to your client, an ambitious user could just change the string in the binary itself.
I tried a number of things because I am in the same situation. I have a very old (Pentium II era) computer that I always have on, and a cronjob runs getmail periodically, which drops the mail off to maildrop, which sorts the mail and delivers it in maildir format (also, the first rule is to copy the message into a backup folder). Then I just run an IMAP server that reads the maildir directories. The reason that I ended up doing this rather than the various other solutions I might have done is that this gives you a lot of flexibility down the road. For example, you can easily send the mail through dspam or SA to do spam filtering. Also, all the mail filtering is done at one place which is nice if you want to sync up another computer.
If you don't have an always-on computer there are various ad-hoc ways to sync mail between two computers (e.g. running rsync). The problem with that is that as the amount of mail you have grows, syncing will take a very long time, much more so than running IMAP. It's best to have the mail all in one place, which pretty much requires an always-on computer.
Another thing that you may want to consider is forwarding mail through Gmail. I have an email account that receives a lot of important mail, but that mail is _only_ locally delivered. I set up my.forward file to send it to a Gmail account, and then I can fetch the mail via POP from that account. This worked pretty well, except for two problems: 1) All your mail will be in one folder, and you can't see what has been classified as spam 2) Gmail tries to keep track of what mail you have retrieved via POP for you, and its POP server pretends not to see mail that you have already fetched unless you manually reconfigure it on your account. So if you fetch all your Gmail mail from one computer, and then wait 24 hours and try to fetch all messages from a second computer, the second computer will only have mail from the past 24 hours.
I have read through the (very few so far) messages in the new mailing list, and based on the discussion there as well as the similar discussions that have taken place in the past, I think that the general consensus is that users should not be using the rpm command line tool for package management. Rpm (the CLI tool, not the format) should be like dpkg in the Debian world -- a very low level tool for package management. If you want something user friendly to use at the command line, use yum, apt-rpm, yast, or whatever other high level tool floats your boat.
In fact, to a large degree it is more important that better rpm bindings (especially for python) be written. This is how yum works -- it is able to do all of this using the python bindings, instead of calling the rpm tool itself. Calling rpm -i foo.rpm should really be a last resort option. (For those that are curious, yum already has a --localinstall option for doing this.)
Honestly, the latency difference is going to be _zero_ for a UDP packet (the protocol that every game I know of uses) and at best one millisecond or so for something like ICMP. It is _not_ going to be 10 ms. To restate what I've already posted elsewhere, if you need to go to the CPU for information about what information is encoded in the packet anyway, the 10 _micro_seconds it takes your CPU to read the header off of a UDP packet is not going to matter. A UDP packet literally has, at most, four fixed width fields, and no options. You do not need a NIC to parse that for you.
It's not like a computer sends you some data and the network card is immediately able to reply. To formulate a response, it probably needs data from the CPU, e.g. about your position, your health, or whatever it is that you need to transfer back and forth in a game.
An ICMP echo reply is totally different though. Unless you have a weird firewall setup going on, it's pretty much just safe to send out the echo response as soon as you get the echo request. So in this situation, you could peg the main CPU and then have the NIC doing the mind numbingly boring task of sending out echo responses without going through the CPU, and in this case you might see a latency improvement of a few milliseconds. But in general the CPU is going to have to do some processing and formulate the correct response anyway, so having a "smart" network card doesn't help.
Remember this folks, no where in the RFC's is there anything that states email will get delivered....
It is true that there is no end-to-end mechanism with SMTP, and for that reason you can't be assured the email will get delivered. But IIRC the RFC's state that you can't tell an SMTP server you get mail from that you really have it until you have the mail committed to _disk_, not just memory. And if you have the mail sitting on the hard drive, nothing short of filesystem corruption should cause you to lose that mail.
I would frankly be pretty surprise if the parsing code (and if this is a buffer overflow, I'm sure it's a flaw in the parser) is significantly different in Word 2007. If I was a betting man I'd wager that Word 2007 is vulnerable as well.
The bandwidth throttling may not be a big deal to you, but on high bandwidth high latency links you can get huge performance improvements (i.e. 10-100x) with proper use of TCP window scaling. In the original TCP spec the window size could be no more than 64 KB, but this behavior was later amended and a TCP option was added to allow you to increase this value.
The optimal window size is (Round Trip Time)*(Bandwidth). For my internet connection (600 KBps) that means that a 64KB window is only adequate for sites whose ping time is no greater than 110 ms. For sites with a higher latency, the amount of bandwidth I can get in a TCP connection between me and this host is artificially limited by my TCP window size.
Right now it generally isn't possible to get a reliable connection after increasing the window size past 64 KB because some older/cheapo routers will not work with TCP windows greater than 64K. But if this gets into Vista and TCP window scaling options started getting heavy use, there would be a lot of pressure on sites with broken routers to get them fixed, and then those of us with high bandwidth connections would reap the benefits.
Hi. I've had my computer turned on for the last three hours running Firefox 2.0 and with a terminal open doing coding. And I'm running Gnome, which isn't exactly a lightweight desktop environment. Let's look at how much memory I'm using:
As far as I know most movie studios and speacial effects companies don't use Windows, and very few use Apples when it comes to video and speacial effects. Many of them do use software that runs on a UNIX derivitive, most notably SUN's Solaris or SGI's IRIX operating systems.
Yeah, maybe ten years ago. Nowadays most movie studios and special effects companies use Windows and OS X. The big ones may have render farms running on some *nix system, but the "creative work" is hardly done in Solaris or IRIX.
Slashdot Mirror
Hmm.... sounds good to me -- I'll take it!
AFAICT the software is only "free" as in beer.
He is referring to the possibility of licensing proprietary formats, like MP3, which has been discussed within Red Hat and Fedora before. Basically, the Red Hat legal department is of the opinion that if Fedora were to distribute MP3 (or other proprietary codecs) support, then Red Hat could get in trouble. Red Hat has more than enough money to purchase a license for MP3, and would probably be willing to do so even for Fedora, which of course they do not make money off of. But the issue is that they cannot purchase a license that would also apply to redistributors. The people at Fedora have decided that this is a sacrifice they are not willing to make -- they want Fedora to be truly free, and fully redistributable.
With quantum encryption you cannot conduct a meaningful MITM attack. This is called the observer effect, and is a very well known and studied phenomenon of quantum mechanics.
I do this every election cycle. I take my ballot, vote on all of the bills, and vote for none of the candidates.
The diversity of packaging formats is definitely a nonissue, because EVERYONE has the source code. Any software that is even moderately popular will be packaged by volunteers. If I need some software that isn't already packaged for me, I grab the source code and compile it. If it's something I plan on sharing with other people, I'll write a spec file and distribute the RPM I build.
.deb format, RPM distros have a huge investment in the .rpm format. Likewise for Gentoo, Arch, Slack, and all the other distros with their own formats. There are legitimate reasons for sticking to native formats because of distributions' build infrastructures and installation backends. As long as the source code is available, everyone will be able to install your software, and everyone will be able to use the format of their preference.
I understand that it would perhaps be more optimal if there was a single package format, but that just isn't going to happen. Debian based distros have an enormous time investment in the
I am far from an RPM guru... but I have written a few in my day. Basically the way that an RPM works is you write a spec file which is just a script that tells RPM what actions to perform to install the actual binary. For example, put this file here, change its permissions, restart the running daemon associated with this package, etc. AFAIK the set of commands that you can give to RPM is limited, and I believe that you are not able to tell it to do things like load kernel modules. So sure, if you install an untrusted RPM it can do all kinds of nasty things like clobber your files, but there are limitations to what RPM can do. If you're really paranoid you can also run rpm with SELinux, which obviously has no analog in the Windows world.
Not to mention I'm sure they'd be thrilled to have basically the entire movie contents floating around the Internet on random people's computers.
This is a result of Gauss' law, which is a standard result in vector calculus. This is a mathematical proof about continuously differentiable vector fields. If you took vector calculus in college you probably proved it. For the potential to not be differentiable would be _really_ degenerate case, which IIRC you just assume doesn't happen because there are standard formulas for different potentials (e.g. electric potential, gravitational potential) and all of them are well behaved.
Two reasons:
1) PDF can embed fonts
2) PDF can embed vector graphics natively.
This is a big deal to me. I am a university student studying math. Aside from the obvious reasons that Microsoft doesn't have any compelling (math) typesetting products, there is simply no way that I could create a paper in Word and be able to send it to you and reasonably expect you to be able to read it. You simply don't have the correct fonts/symbols installed on your computer. And if I have some figures or diagrams in the document, I don't want them in some crappy raster image format. I want them in a vector format. Sure, there's no reason that Microsoft couldn't create a vector image format (or adopt something like SVG), but since Postscript (and by association, PDF) has had this capability for twenty years already there simply isn't any reason to.
Again, there's no reason that Microsoft can't create a competing file format that incorporates vector drawing and embedded fonts. But PDF is good, it is a standard, it is well known, etc. It has very important features that are lacking in the Office file formats (and the reverse is true, but that's not the point), and it simply doesn't make a whole lot of sense to try to incorporate these features in to Office.
How does this implement a two-factor security system?
OpenOffice.org is, in my opinion, the weakest part of the free software desktop experience. It is huge and bloated. It takes 100 MB - 200 MB to install (depending on your operating system), which is way more than it should. It doesn't use any platform's native graphical toolkit. Fonts look like crap in it. Etc, etc.
Honestly, I think that Abiword is orders of magnitude better -- not just in the obvious areas of size and memory footprint, but also in terms of the UI. It looks great in Gnome, and runs on Windows too (and it has a grammar checker!). I'm not a KDE user, but KWord also looks better than OO.o
I don't understand the fixation that people have with Open Office. It's slow. It looks bad. It retains all the things you hated about MS Office. The only things that it has going for it is that it has the most faithful .doc import of any open source office tool, and that it has the best ODT support at the moment. But the day that OO.o dies will be a happy day in my book.
I am a math major (although I don't study prime numbers). This is totally, utterly useless, in a practical sense. Well, it might be useful in the field of CS, although I don't know enough about these project to know if any novel algorithms were used. It is sort of interesting though, because the twin prime conjecture (i.e. the statement that there are an infinite number of such pairs) is still unproven, so it's kind of cool to be able to say "Look, we found another pair!"
(On a side note, I don't know of any mathematicians who doubt the validity of the twin prime conjecture. If you proved that the conjecture was false, then you'd be really famous.)
My understanding is that, among other things, a lot of (poorly written) software is written assuming unrestricted access to the registry, which is why you can't just install and run it locally in Windows.
Yes, it is true that there is a "User Agent" field in the bit torrent protocol, but of course this is easy to modify. My favorite client has a bug in it that has caused it to be banned from some private trackers. Since this was hurting me on some files that I download, I modified the user agent string to cause the client to identify itself as uTorrent 1.6. Problem solved!
I think that the user agent field is fixed width, meaning that even if you don't have access to the source code to your client, an ambitious user could just change the string in the binary itself.
I tried a number of things because I am in the same situation. I have a very old (Pentium II era) computer that I always have on, and a cronjob runs getmail periodically, which drops the mail off to maildrop, which sorts the mail and delivers it in maildir format (also, the first rule is to copy the message into a backup folder). Then I just run an IMAP server that reads the maildir directories. The reason that I ended up doing this rather than the various other solutions I might have done is that this gives you a lot of flexibility down the road. For example, you can easily send the mail through dspam or SA to do spam filtering. Also, all the mail filtering is done at one place which is nice if you want to sync up another computer.
.forward file to send it to a Gmail account, and then I can fetch the mail via POP from that account. This worked pretty well, except for two problems:
If you don't have an always-on computer there are various ad-hoc ways to sync mail between two computers (e.g. running rsync). The problem with that is that as the amount of mail you have grows, syncing will take a very long time, much more so than running IMAP. It's best to have the mail all in one place, which pretty much requires an always-on computer.
Another thing that you may want to consider is forwarding mail through Gmail. I have an email account that receives a lot of important mail, but that mail is _only_ locally delivered. I set up my
1) All your mail will be in one folder, and you can't see what has been classified as spam
2) Gmail tries to keep track of what mail you have retrieved via POP for you, and its POP server pretends not to see mail that you have already fetched unless you manually reconfigure it on your account. So if you fetch all your Gmail mail from one computer, and then wait 24 hours and try to fetch all messages from a second computer, the second computer will only have mail from the past 24 hours.
I have read through the (very few so far) messages in the new mailing list, and based on the discussion there as well as the similar discussions that have taken place in the past, I think that the general consensus is that users should not be using the rpm command line tool for package management. Rpm (the CLI tool, not the format) should be like dpkg in the Debian world -- a very low level tool for package management. If you want something user friendly to use at the command line, use yum, apt-rpm, yast, or whatever other high level tool floats your boat.
In fact, to a large degree it is more important that better rpm bindings (especially for python) be written. This is how yum works -- it is able to do all of this using the python bindings, instead of calling the rpm tool itself. Calling rpm -i foo.rpm should really be a last resort option. (For those that are curious, yum already has a --localinstall option for doing this.)
Honestly, the latency difference is going to be _zero_ for a UDP packet (the protocol that every game I know of uses) and at best one millisecond or so for something like ICMP. It is _not_ going to be 10 ms. To restate what I've already posted elsewhere, if you need to go to the CPU for information about what information is encoded in the packet anyway, the 10 _micro_seconds it takes your CPU to read the header off of a UDP packet is not going to matter. A UDP packet literally has, at most, four fixed width fields, and no options. You do not need a NIC to parse that for you.
It's not like a computer sends you some data and the network card is immediately able to reply. To formulate a response, it probably needs data from the CPU, e.g. about your position, your health, or whatever it is that you need to transfer back and forth in a game.
An ICMP echo reply is totally different though. Unless you have a weird firewall setup going on, it's pretty much just safe to send out the echo response as soon as you get the echo request. So in this situation, you could peg the main CPU and then have the NIC doing the mind numbingly boring task of sending out echo responses without going through the CPU, and in this case you might see a latency improvement of a few milliseconds. But in general the CPU is going to have to do some processing and formulate the correct response anyway, so having a "smart" network card doesn't help.
I would frankly be pretty surprise if the parsing code (and if this is a buffer overflow, I'm sure it's a flaw in the parser) is significantly different in Word 2007. If I was a betting man I'd wager that Word 2007 is vulnerable as well.
The bandwidth throttling may not be a big deal to you, but on high bandwidth high latency links you can get huge performance improvements (i.e. 10-100x) with proper use of TCP window scaling. In the original TCP spec the window size could be no more than 64 KB, but this behavior was later amended and a TCP option was added to allow you to increase this value.
The optimal window size is (Round Trip Time)*(Bandwidth). For my internet connection (600 KBps) that means that a 64KB window is only adequate for sites whose ping time is no greater than 110 ms. For sites with a higher latency, the amount of bandwidth I can get in a TCP connection between me and this host is artificially limited by my TCP window size.
Right now it generally isn't possible to get a reliable connection after increasing the window size past 64 KB because some older/cheapo routers will not work with TCP windows greater than 64K. But if this gets into Vista and TCP window scaling options started getting heavy use, there would be a lot of pressure on sites with broken routers to get them fixed, and then those of us with high bandwidth connections would reap the benefits.