I would say, yes, Java is particularly nasty, and it's good to have a healthy fear of it.
It is the COBOL of this decade, just as PHP is the COBOL of the Web. I am sure my brain would be better off not knowing it.
I'll admit that this is an opinion, not a fact. It is, however, a strong opinion, and I'll continue to tell everyone who will listen. And it is a fact that it is better to learn more than one language, even if your day job demands exactly one.
I genuinely feel that we need something better than X.
I agree -- although X itself is trying to become "better than X" as well.
However, I'm not convinced that Windows has got this right, either. The closest seems to be OS X.
Trivial example: I have two monitors. My laptop's monitor is 1920x1200. My external monitor is 1920x1080. On Linux, this is all I have to know -- if I want a game to run on my external monitor (which is quite a bit bigger), I simply set it to 1920x1080. If I want it to run on my laptop's monitor (say, at a LAN party), I set it to 1920x1200.
On Windows, if I set a game to 1920x1080, it will run on the "primary" monitor -- by default, it will be stretched strangely on my internal monitor. I have to make the external monitor the "primary", thus putting the taskbar there. Which is stupid -- I have more vertical space on the internal, and that's where the taskbar lives on Linux.
One more, while I'm at it -- on Linux, I simply installed. I don't think I had to do anything to enable the drivers -- if I did, it was a few commands which are identical on all nvidia systems. By contrast, on Windows, nvidia was not allowed to distribute drivers for that particular model, and Dell only had Vista drivers on their website -- I had to actually have a Dell tech feed me links via chat.
Also, I consider the dozens of available UI API's, to be a bit of a mess, do I use GTK/QT/*insert random API here*
I don't know. Do I use Swing/SWT/*insert random API here*
Use whatever you want -- it's called a choice, and as a developer, you have even less of an excuse for complaining than an end-user does when presented with the GNOME/KDE question.
As a KDE user, I have a little setting I can set -- enabled by default -- which applies my QT themes to GTK+ apps. I'm sure there's something which does the reverse. So end-users don't have to care what toolkit an app is written in -- it will likely just work, and look like it's supposed to look.
Further, trying to maintain library compatibility requires intense efforts by developers and users alike. Upgrade one lib, you may break a build.
This work is also mostly done by distros.
I consider this to be a much better situation than Windows or OS X. On Windows, everything is statically linked, so if there's a critical bug in a given library, you have to wait for each application to update. On OS X, libraries are either distributed by Apple (so you have to convince Apple to force an upgrade, and you've got the same problem as on Linux), or they're bundled inside the.app folder, meaning that while you probably can update them all, it's not going to be fun.
Both the Windows way and the OS X way also waste disk space and bandwidth -- sometimes insignificant, sometimes not. Just look at the OS X download of vlc, and compare it with the Ubuntu vlc packages.
Compare this to Linux. Critical vulnerability in openssl? One apt-get command and it's fixed. For everything.
I'm sure I'll be modded offtopic as well, but especially for development work, I am much more comfortable on Linux.
I wonder how that's "insightful", and not "flamebait" -- I consider Java to be the nastier of that pair. A quote I've always liked: "Saying Java is great because it works on all platforms is like saying anal sex is great because it works on all genders."
That said, Java is cross-platform, and has had a lot more practice at it than C#. It seems to be trying to make it difficult to not be cross-platform. But I don't think that's a huge concern, these days -- Python and Ruby have decent Windows versions, and there's plenty of cross-platform toolkits for C/C++.
As a user, I only really appreciate Java programs when they're developed by people who didn't care about portability, so it's really fun to find out that they just work on Linux -- but if you're designing something to be portable, that works well.
This is not always the gain you might think. There are cases where the memory management you're doing by yourself -- all those malloc/free calls, plus the implementation of malloc/free itself -- pushes you out of cache enough that a garbage collector is actually faster.
Granted, in C you always have the option of writing or using a garbage collector, or of trying to beat it. But to me, that's like saying you can always do inline assembly, when you think you can beat the C compiler. Technically, yes, you can, but computers are getting fast enough that you really shouldn't have to, 99% of the time.
Give me a break. Of course it is. And no, I'm not going to provide figures for an accepted fact.
I agree that it's generally accepted -- I often make that assumption, and while I assume it's possible to go faster than C, I'm not sure any language has managed to do so with any reliability.
That said, it was an "accepted fact" that manual garbage collection (direct calls to malloc/free) is faster than automatic garbage collection (the norm in high-level languages) -- the assumption being that a programmer could always figure out what policy is best for the situation at hand.
And that is strictly true, but only in the sense that a programmer could manually re-implement a garbage collector. There are cases where garbage collection physically outperforms manually using malloc/free. Even when there is some performance lost, there obviously is an audience for BoehmGC.
You can even just use the preprocessor (#IFDEFINE) to remove the body of the function. Then let the compiler optimize out any use of it. Try that with Python/Ruby.
Easy enough to use, if the VM was smart enough. For instance:
SOME_CONSTANT = false def foo
if SOME_CONSTANT ...
end end
The only real difference is that with Python/Ruby, the above would have to happen at runtime, not compile time. But there are other optimizations which can only happen at runtime -- there is, in fact, an audience for LLVM's implementation of C.
In fact, there was a case in which a certain program running on a certain RISC processor ran faster in an optimized emulator than natively -- on the exact same processor.
Taking all of the above into account, I think it's a reasonable question to ask.
Yes, you're going to make things harder on yourself if you try to use C#, or Visual Basic, etc.
And yes, knowing C will help. A lot.
But the answer is the same, no matter what platform you're on. The answer is, "It depends what you want to do."
For instance: It helps to know C, but if you'll be doing, say, web apps, it would be ludicrous to be doing it in C. If, on the other hand, you're doing things with hard realtime requirements, C might be the upper end of what you'd use. And there's all kinds of things in between.
And how many bugs a week do you have due to misplaced parentheses?
It also sounds as though you weren't doing nearly enough testing, if you were discovering 4 bugs a week -- I don't care what language it is, syntax errors should not be taking you that long to resolve, because you shouldn't be letting enough syntax build up, untested, before realizing there's a problem.
You'll recall that Amazon's "cloud computers" (ugh) are by the hour, and are pretty much root access to a VM. Unless there's a specific legal reason you can't, it's always possible to just download the data -- you'd just pay a bit for the time that instance must be up, and for the data transferred.
However, for those of us who already are using EC2, it's nice to not have to download the whole set -- which can be terabytes, for some of these -- and instead be able to simply mount it from wherever it is and work with it right away. Especially when you consider the cost of downloading terabytes worth of data from Amazon's web services, at 17 cents per gigabyte -- reasonable, but still probably more than you wanted to just query the stuff.
I suspect, also, that at least some of these will be made available via a web service of some sort, maybe even free, by some of those people using that service.
I had something similar happen with an iBook G4 many moons ago, and it taught me a very important lesson: buy the damn warranty, especially with a laptop. I've done it with every laptop I've bought since then, Apple or not, and it's absolutely worth it.
I thought so, too -- then found out it wasn't worth the paper it was printed on.
Apple overnighted me a box, which was cool. I sent my Powerbook back. They took one look at it and said that since there was physical damage (a dent from dropping it a year prior to the display failing here), and because of this, any repairs were out of warranty. Furthermore, since my problem involved the display -- most likely the backlight was burnt out -- they would charge me the cost of repairing the entire laptop -- more than it was worth, at the time.
Contrast this to Dell -- my optical drive stopped working, so they sent someone to my house. First time, they sent him with the wrong drive. Second time, there was a hole right through the box and the drive. Third time, it worked... So, it took forever, but the good news is, they sent someone to my house, and didn't ask many questions about the condition of the laptop itself.
If I ever bought another Mac -- and I probably won't -- I would definitely not pay for the warranty.
The one thing that's really not an option is to just bank on your laptop living through your use of it.
I pretty much assume that when my laptop dies out of warranty, it's an excuse for an upgrade.
Nat+uPNP is perfectly capable and 100% backwords compatible.
NAT is a hack, and uPNP is not universally supported -- not in the routers themselves, and not in every program you might want t ob accessible.
Besides which, there are a limited number of ports, and you're still preventing people from picking a standard port and leaving it open, to connect to it later -- for instance, if my ISP NATs me, how do I ssh or vpn back home? Let alone run a webserver out of my house..
That's not even getting into all the millions of unused IP's being held by the early internet companies.
True, but consider that IPv6 would prevent anything like that from happening again.
Start with $1 per year per ip to EVERYONE who owns an IP's and you'll see the "IP Shortage" vanish overnight.
I'd also very likely see my own public-facing IP go away, and more and more ISPs NAT-ing all their customers -- who are then doubly-NATed behind their routers -- which is then a gigantic pain in the ass to deal with, versus simply upgrading to ipv6.
I'd also likely see my hosting costs go up a bit.
All to manage this artificial scarcity, and push it back for awhile -- which could be so easily dealt with by simply upgrading to ipv6, and giving an IP address to every device on the planet -- and, as a nice side effect, making it possible for me to assign a public-facing IP address and DNS entry for every toaster in my house.
I'm not sure why this would bother Google -- are all SoC projects required to be on Google Code? For instance, if your project is with the Linux Kernel, would you be required to mirror your subtree, or the entire project, on Google Code?
You've supplied plenty of hype, but little substance:
GitTorrent makes Git truly distributed.
Git is already truly distributed. What's more distributed about GitTorrent?
"the web site" no longer becomes the central choke-point of control.
It's not.
For a good example, look at the Linux Kernel itself. Yes, kernel.org exists, but it is not a choke point. There are enough mirrors, and enough branches, that some flavor of the kernel will always be available from somewhere, even if kernel.org goes away for awhile.
Imagine that an entire project - its web site, documentation, wiki, bug-tracker, source code and binaries are all managed and stored in a peer-to-peer distributed git repository.
Alright. What does that buy?
To view the web site, you either go to the main site, http://web-site.org/ or, if you are offline or want faster access, you go to the locally checked out copy.
If we are talking about documentation, most open source projects already include documentation in the repository -- some are generated from the source code itself -- and almost all of it will be installed with the binary package.
Having a local copy when no Internet access is available is a solved problem. It was a solved problem before Git, and GitTorrent adds nothing to that equation.
To contribute to the wiki, you either go the main web site, or you edit the local pages and git push them to the cloud.
First, define "the cloud". No handwaving.
More relevantly: Again, what does this buy? I can already push to website, if it is a wiki, by editing it directly. If it is not, I can already send contributions back. If they are stored in the repository, that's helpful, too -- but what does GitTorrent itself give me over pure Git?
To report a bug, you either go to the main web site, or you run your own local web server that duplicates the bug database, and, once you've reported it, the submit ends up with the bugreport being in the locally checked out git repository which, on a push, gets uploaded into the cloud - and ends up on the main web site.
I would suggest ditz for this purpose, but again, how is this different than pure Git, other than "The Cloud"?
To upgrade to the latest release, you do a git checkout (of the binaries).
And why are the binaries being checked into Git? Ever?
Imagine that you want to fork a project, but you feel intimidated doing so because of the "centralisation". You have no control over the "central web site".
Check out Github, for that. Each project has a web source viewer, a README, a wiki, and the other things you'd expect (as a software developer) when looking at a project.
Forking the project can be done by clicking the "fork" button. You now have your own copy of the source, which is pretty much "the website".
Abandoned projects can easily be revived, through a simple process of a new developer announcing their PGP public key identity, and for Users to start pulling in code that's tagged with that PGP key.
And how do they announce this? How is this announcement more effective than announcing a new project website and name?
Users will be able to decide whom to trust based on who contributes, not on who controls the project's web site.
Already possible. The difference here is, if there's no central website, you're forcing users to go out and learn a version control system, a web-of-trust concept (and make a few trusted friends), and be keenly aware of who is actively contributing and who isn't.
Versus having a simple, central authority, to the point where I don't even need to find the website; I can just use apt-get.
it's not feasible to have that kind of bandwidth sitting around unused except for a few days every 6 months, nor is it currently feasible to get that much bandwidth on-demand for a website
think of google code as a bootstrap mechanism: you have to get from here to there _somehow_, and if it wasn't for the old, you'd never get a leg-up into the new....
True enough, but you'd think that you'd start with one of the "old" things which was at least managed with the same SCM your project is for. That is, why wouldn't you use Github for that?
In such a situation, I still don't see how GitTorrent helps. I can still use Git over a LAN, manually, and that intermittent 56k is still plenty fast for source-level changes to be distributed via Git.
the last major upgrade of debian REDLINED the world's internet backbone infrastructure for a WEEK.
I very much doubt it was the source which caused that issue, or that a distributed git repository would help. I'm guessing it was downloading DVD images, or individual packages -- assuming that this actually happened; I only have your word for it at the moment.
And the reason it doesn't apply to source code management is, at least technologically, git is damned good -- fast and small enough that it really does not cost very much in the way of hosting. Typically, when I send an update to Github, it's on the order of five kilobytes -- in other words, around a second on a 56k connection. Updates are similar -- maybe ten or twenty kilobytes. Maybe a hundred -- twenty seconds on a 56k connection.
Having worked with SVN, I can say that while this kind of wait isn't fun, it does work, and it is productive.
Now, there are ways to use BitTorrent to fetch actual binary packages, but that's a completely separate project.
i don't _want_ "sponsorship". i don't _want_ my pet project hosted by a large corporation. i want it completely independent.
Why not?
they DO NOT have "continuous access to the web site or access to the lovely sponsored hosting".
I don't see where GitTorrent helps them, though. If they have Internet access, there's plenty of free hosting they can use, particularly for open source projects. If they don't have Internet access, I don't see where a Torrent-like system is going to be any different -- they're still going to have to collaborate locally, probably with GitJour or something similar.
But see above -- when they are online, just about any definition of being "online' is going to be fast enough for Git.
I don't see the need, though. Git is small and lightweight. Large-ish projects just work off of Github, which is fast enough. If the central repository goes down, you have other means (mailing list, etc) for getting back in touch -- granted, GitTorrent would do that for you, but it seems a premature optimization when a central repository works most of the time.
For issue tracking, a better example would be ditz, which stores issues as plain text. YAML, actually, but close enough. Thus, rather than thinking about this whole separate layer of SQL transactions, you deal with changes to the bug tracker with the same tools you use for managing the code.
For instance, rather than Trac's retarded behavior of refusing to let you modify an issue when someone else already has (and refusing to let you see their changes without opening a new tab), you'd let Git try to merge them, and fix it manually if necessary.
PHP would not be a good idea, either, unless it was very well secured -- you'd probably want static files for your wiki, or a safer templating language (Markdown, etc). In fact, no need to make it a wiki -- again, just keep it flat, and use git as the mechanism for distributing changes.
I'm not complaining about the lack of hosting. But you're suggesting that in order to host them, I should violate patent law and/or the DMCA in order to convert them from the proprietary formats you've mentioned into a sufficiently open format to host them?
Or are you suggesting that I spend hundreds or thousands of dollars on encoding/mastering software, just to make this supposedly-public-domain work more accessible? Shouldn't that be their job?
I'm not saying that I, personally, am so adverse to breaking the law -- I'd consider it an act of civil disobedience. But I don't think it's appropriate for the president elect to be encouraging unlawful behavior.
The right approach here is to fix copyright law, not to introduce insane new, completely different kinds of law.
In other words, if copyright cannot cover a blank form, try patents. If that doesn't work, try making the case that such a blank form is sufficient IP that it should be protected. Write your congressmen, etc.
But what you are doing is going to break sooner or later -- or so I hope. Far too much control is being exerted over content through DRM -- much of it, as in your case, to prevent your customers from doing something entirely legal that you don't want them to do.
Method doesn't work when improperly implemented. News at 11.
You're basically saying that wear-leveling is no panacea, because not all devices have a good wear-leveling algorithm. Wouldn't the solution, then, to be to demand devices which have a good algorithm, and to reward manufacturers who solve this problem with dollars and word of mouth?
Of course, the sad part is, the devices would probably be simpler, and cheaper to manufacture, if they didn't pretend to be block devices. Only problem is, then OSes (probably filesystems) would have to implement wear-leveling on their own, and Linux is the only one I know of which currently does that.
Still, it would be nice if we could fix that problem in software, rather than letting manufacturers get it wrong.
If you have enough RAM, you probably won't be swapping anyway, whether or not the partition exists. So a swap partition is no harm, in that case, unless you're tweaking swappiness.
If you don't have enough RAM, I'll take whatever imagined risks you've suggested over the very real risk of the OOM-killer trying to reclaim memory, or of the system actually locking up or crashing.
In this case, my assumption is that this person is booting a USB flash drive on whatever computer they have to use at the moment -- therefore, adding more RAM isn't an option. They either have enough or they don't, but they certainly don't have any say about it.
This is because they measure their output by quantity.
That's fine -- just measure it as a combined quantity of bills passed and bills repealed.
Or measure it as a quantity of money you saved the taxpayers, or of people who have actually been positively affected by what you're doing.
IMO, the ideal congressman sits on his ass all day because nothing needs changing.
But do you actually believe nothing needs changing? Would you bother to vote for an incumbent if you were so content? You'd probably be much more interested in voting the bums out when you aren't content...
I agree, in principle, but in practice, there's far too much broken, and it takes Congress far too long to address most of it, for any congressman to sit on his (or her) well-dressed, re-election-campaigning ass.
Slashdot Mirror
I would say, yes, Java is particularly nasty, and it's good to have a healthy fear of it.
It is the COBOL of this decade, just as PHP is the COBOL of the Web. I am sure my brain would be better off not knowing it.
I'll admit that this is an opinion, not a fact. It is, however, a strong opinion, and I'll continue to tell everyone who will listen. And it is a fact that it is better to learn more than one language, even if your day job demands exactly one.
I genuinely feel that we need something better than X.
I agree -- although X itself is trying to become "better than X" as well.
However, I'm not convinced that Windows has got this right, either. The closest seems to be OS X.
Trivial example: I have two monitors. My laptop's monitor is 1920x1200. My external monitor is 1920x1080. On Linux, this is all I have to know -- if I want a game to run on my external monitor (which is quite a bit bigger), I simply set it to 1920x1080. If I want it to run on my laptop's monitor (say, at a LAN party), I set it to 1920x1200.
On Windows, if I set a game to 1920x1080, it will run on the "primary" monitor -- by default, it will be stretched strangely on my internal monitor. I have to make the external monitor the "primary", thus putting the taskbar there. Which is stupid -- I have more vertical space on the internal, and that's where the taskbar lives on Linux.
One more, while I'm at it -- on Linux, I simply installed. I don't think I had to do anything to enable the drivers -- if I did, it was a few commands which are identical on all nvidia systems. By contrast, on Windows, nvidia was not allowed to distribute drivers for that particular model, and Dell only had Vista drivers on their website -- I had to actually have a Dell tech feed me links via chat.
Also, I consider the dozens of available UI API's, to be a bit of a mess, do I use GTK/QT/*insert random API here*
I don't know. Do I use Swing/SWT/*insert random API here*
Use whatever you want -- it's called a choice, and as a developer, you have even less of an excuse for complaining than an end-user does when presented with the GNOME/KDE question.
As a KDE user, I have a little setting I can set -- enabled by default -- which applies my QT themes to GTK+ apps. I'm sure there's something which does the reverse. So end-users don't have to care what toolkit an app is written in -- it will likely just work, and look like it's supposed to look.
Further, trying to maintain library compatibility requires intense efforts by developers and users alike. Upgrade one lib, you may break a build.
This work is also mostly done by distros.
I consider this to be a much better situation than Windows or OS X. On Windows, everything is statically linked, so if there's a critical bug in a given library, you have to wait for each application to update. On OS X, libraries are either distributed by Apple (so you have to convince Apple to force an upgrade, and you've got the same problem as on Linux), or they're bundled inside the .app folder, meaning that while you probably can update them all, it's not going to be fun.
Both the Windows way and the OS X way also waste disk space and bandwidth -- sometimes insignificant, sometimes not. Just look at the OS X download of vlc, and compare it with the Ubuntu vlc packages.
Compare this to Linux. Critical vulnerability in openssl? One apt-get command and it's fixed. For everything.
I'm sure I'll be modded offtopic as well, but especially for development work, I am much more comfortable on Linux.
Using Java avoids most of the nastiness of Linux
I wonder how that's "insightful", and not "flamebait" -- I consider Java to be the nastier of that pair. A quote I've always liked: "Saying Java is great because it works on all platforms is like saying anal sex is great because it works on all genders."
That said, Java is cross-platform, and has had a lot more practice at it than C#. It seems to be trying to make it difficult to not be cross-platform. But I don't think that's a huge concern, these days -- Python and Ruby have decent Windows versions, and there's plenty of cross-platform toolkits for C/C++.
As a user, I only really appreciate Java programs when they're developed by people who didn't care about portability, so it's really fun to find out that they just work on Linux -- but if you're designing something to be portable, that works well.
This is not always the gain you might think. There are cases where the memory management you're doing by yourself -- all those malloc/free calls, plus the implementation of malloc/free itself -- pushes you out of cache enough that a garbage collector is actually faster.
Granted, in C you always have the option of writing or using a garbage collector, or of trying to beat it. But to me, that's like saying you can always do inline assembly, when you think you can beat the C compiler. Technically, yes, you can, but computers are getting fast enough that you really shouldn't have to, 99% of the time.
Give me a break. Of course it is. And no, I'm not going to provide figures for an accepted fact.
I agree that it's generally accepted -- I often make that assumption, and while I assume it's possible to go faster than C, I'm not sure any language has managed to do so with any reliability.
That said, it was an "accepted fact" that manual garbage collection (direct calls to malloc/free) is faster than automatic garbage collection (the norm in high-level languages) -- the assumption being that a programmer could always figure out what policy is best for the situation at hand.
And that is strictly true, but only in the sense that a programmer could manually re-implement a garbage collector. There are cases where garbage collection physically outperforms manually using malloc/free. Even when there is some performance lost, there obviously is an audience for BoehmGC.
You can even just use the preprocessor (#IFDEFINE) to remove the body of the function. Then let the compiler optimize out any use of it. Try that with Python/Ruby.
Easy enough to use, if the VM was smart enough. For instance:
The only real difference is that with Python/Ruby, the above would have to happen at runtime, not compile time. But there are other optimizations which can only happen at runtime -- there is, in fact, an audience for LLVM's implementation of C.
In fact, there was a case in which a certain program running on a certain RISC processor ran faster in an optimized emulator than natively -- on the exact same processor.
Taking all of the above into account, I think it's a reasonable question to ask.
Yes, you're going to make things harder on yourself if you try to use C#, or Visual Basic, etc.
And yes, knowing C will help. A lot.
But the answer is the same, no matter what platform you're on. The answer is, "It depends what you want to do."
For instance: It helps to know C, but if you'll be doing, say, web apps, it would be ludicrous to be doing it in C. If, on the other hand, you're doing things with hard realtime requirements, C might be the upper end of what you'd use. And there's all kinds of things in between.
And how many bugs a week do you have due to misplaced parentheses?
It also sounds as though you weren't doing nearly enough testing, if you were discovering 4 bugs a week -- I don't care what language it is, syntax errors should not be taking you that long to resolve, because you shouldn't be letting enough syntax build up, untested, before realizing there's a problem.
You'll recall that Amazon's "cloud computers" (ugh) are by the hour, and are pretty much root access to a VM. Unless there's a specific legal reason you can't, it's always possible to just download the data -- you'd just pay a bit for the time that instance must be up, and for the data transferred.
However, for those of us who already are using EC2, it's nice to not have to download the whole set -- which can be terabytes, for some of these -- and instead be able to simply mount it from wherever it is and work with it right away. Especially when you consider the cost of downloading terabytes worth of data from Amazon's web services, at 17 cents per gigabyte -- reasonable, but still probably more than you wanted to just query the stuff.
I suspect, also, that at least some of these will be made available via a web service of some sort, maybe even free, by some of those people using that service.
I had something similar happen with an iBook G4 many moons ago, and it taught me a very important lesson: buy the damn warranty, especially with a laptop. I've done it with every laptop I've bought since then, Apple or not, and it's absolutely worth it.
I thought so, too -- then found out it wasn't worth the paper it was printed on.
Apple overnighted me a box, which was cool. I sent my Powerbook back. They took one look at it and said that since there was physical damage (a dent from dropping it a year prior to the display failing here), and because of this, any repairs were out of warranty. Furthermore, since my problem involved the display -- most likely the backlight was burnt out -- they would charge me the cost of repairing the entire laptop -- more than it was worth, at the time.
Contrast this to Dell -- my optical drive stopped working, so they sent someone to my house. First time, they sent him with the wrong drive. Second time, there was a hole right through the box and the drive. Third time, it worked... So, it took forever, but the good news is, they sent someone to my house, and didn't ask many questions about the condition of the laptop itself.
If I ever bought another Mac -- and I probably won't -- I would definitely not pay for the warranty.
The one thing that's really not an option is to just bank on your laptop living through your use of it.
I pretty much assume that when my laptop dies out of warranty, it's an excuse for an upgrade.
Nat+uPNP is perfectly capable and 100% backwords compatible.
NAT is a hack, and uPNP is not universally supported -- not in the routers themselves, and not in every program you might want t ob accessible.
Besides which, there are a limited number of ports, and you're still preventing people from picking a standard port and leaving it open, to connect to it later -- for instance, if my ISP NATs me, how do I ssh or vpn back home? Let alone run a webserver out of my house..
That's not even getting into all the millions of unused IP's being held by the early internet companies.
True, but consider that IPv6 would prevent anything like that from happening again.
Start with $1 per year per ip to EVERYONE who owns an IP's and you'll see the "IP Shortage" vanish overnight.
I'd also very likely see my own public-facing IP go away, and more and more ISPs NAT-ing all their customers -- who are then doubly-NATed behind their routers -- which is then a gigantic pain in the ass to deal with, versus simply upgrading to ipv6.
I'd also likely see my hosting costs go up a bit.
All to manage this artificial scarcity, and push it back for awhile -- which could be so easily dealt with by simply upgrading to ipv6, and giving an IP address to every device on the planet -- and, as a nice side effect, making it possible for me to assign a public-facing IP address and DNS entry for every toaster in my house.
I'm not sure why this would bother Google -- are all SoC projects required to be on Google Code? For instance, if your project is with the Linux Kernel, would you be required to mirror your subtree, or the entire project, on Google Code?
You've supplied plenty of hype, but little substance:
GitTorrent makes Git truly distributed.
Git is already truly distributed. What's more distributed about GitTorrent?
"the web site" no longer becomes the central choke-point of control.
It's not.
For a good example, look at the Linux Kernel itself. Yes, kernel.org exists, but it is not a choke point. There are enough mirrors, and enough branches, that some flavor of the kernel will always be available from somewhere, even if kernel.org goes away for awhile.
Imagine that an entire project - its web site, documentation, wiki, bug-tracker, source code and binaries are all managed and stored in a peer-to-peer distributed git repository.
Alright. What does that buy?
To view the web site, you either go to the main site, http://web-site.org/ or, if you are offline or want faster access, you go to the locally checked out copy.
If we are talking about documentation, most open source projects already include documentation in the repository -- some are generated from the source code itself -- and almost all of it will be installed with the binary package.
Having a local copy when no Internet access is available is a solved problem. It was a solved problem before Git, and GitTorrent adds nothing to that equation.
To contribute to the wiki, you either go the main web site, or you edit the local pages and git push them to the cloud.
First, define "the cloud". No handwaving.
More relevantly: Again, what does this buy? I can already push to website, if it is a wiki, by editing it directly. If it is not, I can already send contributions back. If they are stored in the repository, that's helpful, too -- but what does GitTorrent itself give me over pure Git?
To report a bug, you either go to the main web site, or you run your own local web server that duplicates the bug database, and, once you've reported it, the submit ends up with the bugreport being in the locally checked out git repository which, on a push, gets uploaded into the cloud - and ends up on the main web site.
I would suggest ditz for this purpose, but again, how is this different than pure Git, other than "The Cloud"?
To upgrade to the latest release, you do a git checkout (of the binaries).
And why are the binaries being checked into Git? Ever?
Imagine that you want to fork a project, but you feel intimidated doing so because of the "centralisation". You have no control over the "central web site".
Check out Github, for that. Each project has a web source viewer, a README, a wiki, and the other things you'd expect (as a software developer) when looking at a project.
Forking the project can be done by clicking the "fork" button. You now have your own copy of the source, which is pretty much "the website".
Abandoned projects can easily be revived, through a simple process of a new developer announcing their PGP public key identity, and for Users to start pulling in code that's tagged with that PGP key.
And how do they announce this? How is this announcement more effective than announcing a new project website and name?
Users will be able to decide whom to trust based on who contributes, not on who controls the project's web site.
Already possible. The difference here is, if there's no central website, you're forcing users to go out and learn a version control system, a web-of-trust concept (and make a few trusted friends), and be keenly aware of who is actively contributing and who isn't.
Versus having a simple, central authority, to the point where I don't even need to find the website; I can just use apt-get.
In combination with autom
it's not feasible to have that kind of bandwidth sitting around unused except for a few days every 6 months, nor is it currently feasible to get that much bandwidth on-demand for a website
Ahem.
It costs money, yes -- but it's certainly possible.
think of google code as a bootstrap mechanism: you have to get from here to there _somehow_, and if it wasn't for the old, you'd never get a leg-up into the new....
True enough, but you'd think that you'd start with one of the "old" things which was at least managed with the same SCM your project is for. That is, why wouldn't you use Github for that?
In such a situation, I still don't see how GitTorrent helps. I can still use Git over a LAN, manually, and that intermittent 56k is still plenty fast for source-level changes to be distributed via Git.
the last major upgrade of debian REDLINED the world's internet backbone infrastructure for a WEEK.
I very much doubt it was the source which caused that issue, or that a distributed git repository would help. I'm guessing it was downloading DVD images, or individual packages -- assuming that this actually happened; I only have your word for it at the moment.
And the reason it doesn't apply to source code management is, at least technologically, git is damned good -- fast and small enough that it really does not cost very much in the way of hosting. Typically, when I send an update to Github, it's on the order of five kilobytes -- in other words, around a second on a 56k connection. Updates are similar -- maybe ten or twenty kilobytes. Maybe a hundred -- twenty seconds on a 56k connection.
Having worked with SVN, I can say that while this kind of wait isn't fun, it does work, and it is productive.
Now, there are ways to use BitTorrent to fetch actual binary packages, but that's a completely separate project.
i don't _want_ "sponsorship". i don't _want_ my pet project hosted by a large corporation. i want it completely independent.
Why not?
they DO NOT have "continuous access to the web site or access to the lovely sponsored hosting".
I don't see where GitTorrent helps them, though. If they have Internet access, there's plenty of free hosting they can use, particularly for open source projects. If they don't have Internet access, I don't see where a Torrent-like system is going to be any different -- they're still going to have to collaborate locally, probably with GitJour or something similar.
But see above -- when they are online, just about any definition of being "online' is going to be fast enough for Git.
I don't see the need, though. Git is small and lightweight. Large-ish projects just work off of Github, which is fast enough. If the central repository goes down, you have other means (mailing list, etc) for getting back in touch -- granted, GitTorrent would do that for you, but it seems a premature optimization when a central repository works most of the time.
Using sqlite would probably not work very well.
For issue tracking, a better example would be ditz, which stores issues as plain text. YAML, actually, but close enough. Thus, rather than thinking about this whole separate layer of SQL transactions, you deal with changes to the bug tracker with the same tools you use for managing the code.
For instance, rather than Trac's retarded behavior of refusing to let you modify an issue when someone else already has (and refusing to let you see their changes without opening a new tab), you'd let Git try to merge them, and fix it manually if necessary.
PHP would not be a good idea, either, unless it was very well secured -- you'd probably want static files for your wiki, or a safer templating language (Markdown, etc). In fact, no need to make it a wiki -- again, just keep it flat, and use git as the mechanism for distributing changes.
I'm not complaining about the lack of hosting. But you're suggesting that in order to host them, I should violate patent law and/or the DMCA in order to convert them from the proprietary formats you've mentioned into a sufficiently open format to host them?
Or are you suggesting that I spend hundreds or thousands of dollars on encoding/mastering software, just to make this supposedly-public-domain work more accessible? Shouldn't that be their job?
I'm not saying that I, personally, am so adverse to breaking the law -- I'd consider it an act of civil disobedience. But I don't think it's appropriate for the president elect to be encouraging unlawful behavior.
The right approach here is to fix copyright law, not to introduce insane new, completely different kinds of law.
In other words, if copyright cannot cover a blank form, try patents. If that doesn't work, try making the case that such a blank form is sufficient IP that it should be protected. Write your congressmen, etc.
But what you are doing is going to break sooner or later -- or so I hope. Far too much control is being exerted over content through DRM -- much of it, as in your case, to prevent your customers from doing something entirely legal that you don't want them to do.
Method doesn't work when improperly implemented. News at 11.
You're basically saying that wear-leveling is no panacea, because not all devices have a good wear-leveling algorithm. Wouldn't the solution, then, to be to demand devices which have a good algorithm, and to reward manufacturers who solve this problem with dollars and word of mouth?
Of course, the sad part is, the devices would probably be simpler, and cheaper to manufacture, if they didn't pretend to be block devices. Only problem is, then OSes (probably filesystems) would have to implement wear-leveling on their own, and Linux is the only one I know of which currently does that.
Still, it would be nice if we could fix that problem in software, rather than letting manufacturers get it wrong.
Why not?
If you have enough RAM, you probably won't be swapping anyway, whether or not the partition exists. So a swap partition is no harm, in that case, unless you're tweaking swappiness.
If you don't have enough RAM, I'll take whatever imagined risks you've suggested over the very real risk of the OOM-killer trying to reclaim memory, or of the system actually locking up or crashing.
In this case, my assumption is that this person is booting a USB flash drive on whatever computer they have to use at the moment -- therefore, adding more RAM isn't an option. They either have enough or they don't, but they certainly don't have any say about it.
Is this true of PayPal, specifically?
Thanks.
Doesn't change my point -- what's the point of public-domaining them when there are so few results of this which are both legal and practical?
Public domain, like open source, requires more than just a license.
This is because they measure their output by quantity.
That's fine -- just measure it as a combined quantity of bills passed and bills repealed.
Or measure it as a quantity of money you saved the taxpayers, or of people who have actually been positively affected by what you're doing.
IMO, the ideal congressman sits on his ass all day because nothing needs changing.
But do you actually believe nothing needs changing? Would you bother to vote for an incumbent if you were so content? You'd probably be much more interested in voting the bums out when you aren't content...
I agree, in principle, but in practice, there's far too much broken, and it takes Congress far too long to address most of it, for any congressman to sit on his (or her) well-dressed, re-election-campaigning ass.