He's right though. Any comment which is critical of macs and doesn't mention being moderated down gets moderated down as a troll or flamebait, regardless of how reasonable it is. Look at the apple threads, really, you can't deny it's happening.
Seems a bit silly to me considering the mature Qt/Embedded exists, while afaik there's nothing like that for GTK, and certainly not at the same level of maturity.
In addition to things others have suggested, take a look at openmosix. Just run the openmosix kernel on all the computers in a business and they can migrate jobs from ones which are busy to those that aren't.
It relies entirely on the compiler, yes, but writing a good optimising compiler is *bloody difficult*. As you say, the language can help. Making use of this in Haskell should be fairly easy, because the consequences of each function are clearly defined. Making use of it in C (without requiring the programmer to give hints) may very well be impossible.
I think tending towards an Itanium-like design is inevitable, but Itanium itself was too far ahead of it's time. You can't make the leap straight to the compiler having to do everything while having the 3-instructions parallelism when people have been used to x86's peephole optimisation for so long. I think Intel would do well to mothball it, keep a small team working on the compiler and keeping the design more or less up to date, then reintroduce it when people are more used to these sort of things. There are lots of very good things about Itanium, and it's better than kludging these sorts of things into x86 - but people will only appreciate it after they've had some experience with them.
The first part you get is not the start of the file, but you can make it that way, so it would presumably be possible to get a whole file by pretending to be new people every so often. I think leeching must be possible, though I'm not inclined to write a leeching client to prove it.
WebKit doesn't meet KDE's coding standards. They're quite strict, in order to keep a clean codebase, wheras Apple has rushed features in to a certain extent. Also, KHTML is integrated into KDE, and a large part of the difference between it and WebKit is that Apple have done a lot of work to remove that integration (and add their own). I suspect the reason Nokia are using WebKit is it is mostly de-integrated. Porting to KDE would just mean adding all the integration back in. (kparts, kwallet, etc.). Not too much work, but pretty pointless because the result would be very similar to KHTML.
You can download without uploading to a certain extent. (If nothing else, you must be able to download something before you upload anything). It's impossible to have a majority of leechers, but you can have a few good sharers and the rest leechers, which results in slower downloads for everyone, but more safety and free upload bandwidth for the leechers.
It must be possible to get things without giving, otherwise no one would be able to join a torrent (because they'd have nothing to upload). So there's a way to leech. And there will be people who make it work.
Even better, try saving as rtf. I was working on a piece of physics coursework in word and wanted to send it home. It had several embedded pictures and graphs and things. 6mb.doc file. I thought I'd try saving it as rtf to send home, since KOffice doesn't always import.doc files correctly.
It was, no joke, 180mb
I got it home and opened in OOo writer (I was right, KOffice didn't get everything correct, so I thought I'd use that as a conversion step). I verified everything had imported correctly, added a few more graphs and things (finishing it off) and saved as rtf.
1.2mb. Over two orders of magnitude smaller.
The document is here if anyone wants to try and duplicate the result.
If it's timebombed that makes a non-timebombed version worth more. So the stripped version will be what gets distributed. I can't believe someone hasn't tried putting their clock forwards to see if there is a timebomb.
I've never seen a P2P network without leechers. Even those which include an economics system like edonkey still have their share. I don't think there's anything fundamentally different about bittorrent. Now it's pretty much an ordinary P2P net leechers will appear. The economics will help limit their impact though.
He's just using statistics to detect emails that are "different". So, anyone who isn't conforming is flagged up. Organising an anti-war protest? There you are, flagged. Say goodbye to freedom, if you hadn't already. Or encrypt all your emails, and try and persuade everyone you know to. Maybe we can make encryption widespread enough these things are useless.
Re:When four corners is too much
on
Drafting GPL3
·
· Score: 1
They include non-GPL things, for example they acknowledge that MIT's X11 which was available under a very liberal license made GNU a lot easier, and other things like TeX. I feel if that much PD code was around there would be a note in someone's history, if not the FSF's own then someone would set them right. But perhaps not.
It must be system level, because real attempted to license the DRM and were refused.
It is a bit of a disjointed comparison, but to my eye there are similarities. People are locked out by the use of DRMed AAC even though the open mp3 format exists. DRMed WMV files won't play on an ipod but that's simply because Apple haven't licensed it, MS will let anyone who pays their fees (IIRC $20000 plus a royalty on each player sold, but don't quote me on it) add support to their player, or sell those files in their store. Wheras real approached Apple, saying they were willing to license the AAC drm on similar terms so they could sell tracks for the ipod from their music store, and were basically told Apple wasn't interested no matter how much money they offered.
It's been pointed out repeatedly but it's still wrong. If you read Apple's statements to shareholders you'll see iTMS is a major profit center.
Though you can change the format used in itunes, you can't change the format iTMS sells in. You get tracks you can't play on any non-ipod portable player, you have to lose quite a bit of quality or space and go through a tiresome conversion to make them MP3s, certainly much more convoluted than changing a dialog box to save as rtf. But the main monopolising is having iPods only play one type of drm file and refusing to license it to other music stores. The fact that the ipod can play other non-drm formats is immaterial since major-label music is only available to sell in drmed formats.
If vim doesn't do something I want, I can extend it with C, and I already know that (I know I should learn lisp, but other things get in the way).
When I'm coding a project I use kdevelop. I probably don't use a tenth of its features though. It sets up autoconf for me, integrates the Qt and KDE documentation, includes Qt designer (embedded as a kpart or something, it goes in the same place as the text editor component) and fits in nicely with KDE, and by and large that's all I need.
Who still uses one application at a time, really? I know there's less benefit when it's different applications because of register sharing, but if it's cheaper to get 4 cores than 2 cpus it's probably worth it.
It includes things that aren't in the repositories, and versions are generally not "matching" across apps (stable versions are used for some apps, not for others, so you're not in sync with any particular source. Someone could set up a knoppix repository I suppose, but there doesn't seem to be one at the moment). It looks like a recipe for horrible problems from stale apps in the future. Maybe I'm being overly cautious.
RTFP I was replying to, they said "Apple does not have a monopoly". Anyway, I think they're abusing it by refusing to license the DRM they use to other music stores, so only they can sell major-label music for the ipod.
Well, the main reason is that there are few independent hashing algorithms. So if you can make a set of files that hash the same under one, it's more likely that they'll hash the same under another. For the extra bits you're using, it's far more effective to use a longer version of one of the hashes (e.g. sha-256 or 512). Schneier (sp?) explains it better than I do.
No, I mean the statement you use when licensing your program under it. "This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version." Seems pretty clear to me.
Slashdot Mirror
He's right though. Any comment which is critical of macs and doesn't mention being moderated down gets moderated down as a troll or flamebait, regardless of how reasonable it is. Look at the apple threads, really, you can't deny it's happening.
How did you choose which BSD to use? How did you choose to use BSD rather than linux? Weren't there just as many for/againsts on all the reviews?
Seems a bit silly to me considering the mature Qt/Embedded exists, while afaik there's nothing like that for GTK, and certainly not at the same level of maturity.
In addition to things others have suggested, take a look at openmosix. Just run the openmosix kernel on all the computers in a business and they can migrate jobs from ones which are busy to those that aren't.
It relies entirely on the compiler, yes, but writing a good optimising compiler is *bloody difficult*. As you say, the language can help. Making use of this in Haskell should be fairly easy, because the consequences of each function are clearly defined. Making use of it in C (without requiring the programmer to give hints) may very well be impossible.
JIT is a) sucky and b) already done, since x86 is usually just RISC pretending.
I think tending towards an Itanium-like design is inevitable, but Itanium itself was too far ahead of it's time. You can't make the leap straight to the compiler having to do everything while having the 3-instructions parallelism when people have been used to x86's peephole optimisation for so long. I think Intel would do well to mothball it, keep a small team working on the compiler and keeping the design more or less up to date, then reintroduce it when people are more used to these sort of things. There are lots of very good things about Itanium, and it's better than kludging these sorts of things into x86 - but people will only appreciate it after they've had some experience with them.
The first part you get is not the start of the file, but you can make it that way, so it would presumably be possible to get a whole file by pretending to be new people every so often. I think leeching must be possible, though I'm not inclined to write a leeching client to prove it.
WebKit doesn't meet KDE's coding standards. They're quite strict, in order to keep a clean codebase, wheras Apple has rushed features in to a certain extent. Also, KHTML is integrated into KDE, and a large part of the difference between it and WebKit is that Apple have done a lot of work to remove that integration (and add their own). I suspect the reason Nokia are using WebKit is it is mostly de-integrated. Porting to KDE would just mean adding all the integration back in. (kparts, kwallet, etc.). Not too much work, but pretty pointless because the result would be very similar to KHTML.
You can download without uploading to a certain extent. (If nothing else, you must be able to download something before you upload anything). It's impossible to have a majority of leechers, but you can have a few good sharers and the rest leechers, which results in slower downloads for everyone, but more safety and free upload bandwidth for the leechers.
It must be possible to get things without giving, otherwise no one would be able to join a torrent (because they'd have nothing to upload). So there's a way to leech. And there will be people who make it work.
There's a reasonable howto here.
Sorry, I missed a quote. The document is here if anyone wants to try and duplicate the result.
It was, no joke, 180mb
I got it home and opened in OOo writer (I was right, KOffice didn't get everything correct, so I thought I'd use that as a conversion step). I verified everything had imported correctly, added a few more graphs and things (finishing it off) and saved as rtf.
1.2mb. Over two orders of magnitude smaller.
The document is here if anyone wants to try and duplicate the result.
If it's timebombed that makes a non-timebombed version worth more. So the stripped version will be what gets distributed. I can't believe someone hasn't tried putting their clock forwards to see if there is a timebomb.
I've never seen a P2P network without leechers. Even those which include an economics system like edonkey still have their share. I don't think there's anything fundamentally different about bittorrent. Now it's pretty much an ordinary P2P net leechers will appear. The economics will help limit their impact though.
He's just using statistics to detect emails that are "different". So, anyone who isn't conforming is flagged up. Organising an anti-war protest? There you are, flagged. Say goodbye to freedom, if you hadn't already. Or encrypt all your emails, and try and persuade everyone you know to. Maybe we can make encryption widespread enough these things are useless.
They include non-GPL things, for example they acknowledge that MIT's X11 which was available under a very liberal license made GNU a lot easier, and other things like TeX. I feel if that much PD code was around there would be a note in someone's history, if not the FSF's own then someone would set them right. But perhaps not.
It is a bit of a disjointed comparison, but to my eye there are similarities. People are locked out by the use of DRMed AAC even though the open mp3 format exists. DRMed WMV files won't play on an ipod but that's simply because Apple haven't licensed it, MS will let anyone who pays their fees (IIRC $20000 plus a royalty on each player sold, but don't quote me on it) add support to their player, or sell those files in their store. Wheras real approached Apple, saying they were willing to license the AAC drm on similar terms so they could sell tracks for the ipod from their music store, and were basically told Apple wasn't interested no matter how much money they offered.
It's been pointed out repeatedly but it's still wrong. If you read Apple's statements to shareholders you'll see iTMS is a major profit center.
Though you can change the format used in itunes, you can't change the format iTMS sells in. You get tracks you can't play on any non-ipod portable player, you have to lose quite a bit of quality or space and go through a tiresome conversion to make them MP3s, certainly much more convoluted than changing a dialog box to save as rtf. But the main monopolising is having iPods only play one type of drm file and refusing to license it to other music stores. The fact that the ipod can play other non-drm formats is immaterial since major-label music is only available to sell in drmed formats.
When I'm coding a project I use kdevelop. I probably don't use a tenth of its features though. It sets up autoconf for me, integrates the Qt and KDE documentation, includes Qt designer (embedded as a kpart or something, it goes in the same place as the text editor component) and fits in nicely with KDE, and by and large that's all I need.
Who still uses one application at a time, really? I know there's less benefit when it's different applications because of register sharing, but if it's cheaper to get 4 cores than 2 cpus it's probably worth it.
It includes things that aren't in the repositories, and versions are generally not "matching" across apps (stable versions are used for some apps, not for others, so you're not in sync with any particular source. Someone could set up a knoppix repository I suppose, but there doesn't seem to be one at the moment). It looks like a recipe for horrible problems from stale apps in the future. Maybe I'm being overly cautious.
RTFP I was replying to, they said "Apple does not have a monopoly". Anyway, I think they're abusing it by refusing to license the DRM they use to other music stores, so only they can sell major-label music for the ipod.
Well, the main reason is that there are few independent hashing algorithms. So if you can make a set of files that hash the same under one, it's more likely that they'll hash the same under another. For the extra bits you're using, it's far more effective to use a longer version of one of the hashes (e.g. sha-256 or 512). Schneier (sp?) explains it better than I do.
No, I mean the statement you use when licensing your program under it. "This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version." Seems pretty clear to me.