Of course, IANAL, but I think the reference to CCNV vs. Reid is totally off base. That case rules that a commissioned statue isn't a "work for hire", and thus those rules don't apply. Contract software most certainly IS work for hire. You're copyright most certain does go to the party that pays for the work.
At least, that is what everything I have ever read or heard implies.
In the home there are very few devices that I would want to have on a wireless network that do not have
an AC cord attached - so power consumption is not a big issue.
Well, then they're not very wireless, are they? Too bad networking-over-power-cables never panned out.
The linux kernel may be up for a year or more, but seldom will the applications also be up for that long. With orthogonal persistence, applications may never be "rebooted" -- i.e., started and stopped.
By very careful development, the kernel has been made very stable. However, applications are far from that stable. So when I say that practice needs to be improved, I mean that the correctness of the kernel has to be extended to the system as a whole. Or some other technique of partitioning has to be created, because the partitioning we use in Unix (processes) is part of what orthogonal persistence seeks to eliminate.
By faux-memory-leaks, I mean the memory leaks you get even when you have garbage collection. Typically dictionaries are the most egregious data structure -- it's easy for objects to be left in a dictionary after their usefulness has passed. Also, any named object can't be garbage collected.
Caching can also lead to such memory leaks. It's a different style of problem from in C, but it definitely still exists.
Also, garbage collection on a few gigs of interrelated data isn't easy. Single-pass definitely won't work, but there are a lot of good incremental garbage collection algorithms.
Current theory can mostly deal with a large number of persistant objects -- though in many areas it's just theory. Current practice definitely can't deal with this sort of persistance.
"Persistence" is what a filesystem provides, and RAM does not -- the object can remain in existance indefinitely.
"Serialization" means you take your object and turn it into a stream of bytes of some sort. Some more introspective languages, like Python, Smalltalk, and Java allow very easy serialization, but in something like C you spend a lot of time figuring out how to do it. Even if it is indirect, most files somehow represent an object that was in memory and can be put back into memory at a later time.
"Orthogonal" means that something is seperate from something else -- or more specifically, that while two aspects of a thing are related, you can work with one without effecting the other. Kind of -- it's a subtle (though very useful) notion.
"Orthogonal Peristence" means that all objects persist indefinitely with no effort from the programmer. "Orthogonal" refers to the fact that the persistence happens without any relation to other aspects of the program -- everything just persists by default. While it may involve serialization, this is hidden from the programmer, as is any other technique that supplies the persistance.
In such a system there wouldn't be any distinction between objects in RAM or on a disk -- often that is then expanded to objects that are also remote (similar to CORBA, but again, the network access is orthogonal and invisible). Anyway, the system moves things to disk as it needs to, and pulls them off as needed.
I brought up the cleanliness issue before, but the other issue is scaling. Particularly something like garbage collection is a bit difficult, because you can't just do a mark-and-sweep every so often, because anything on the entire disk could contain a reference.
EROS has this, Smalltalks have generally had this (you might wish to look at Squeak), and the old Lisp machines also tended to have orthogonal persistence.
I dunno about the database idea. Is the filesystem going to be replaced by one specific set of tables with conventional fields? I can see how that would be done, but I honestly can't see why. You just got another heap of data with a different set of metadata.
The other option is a database with dynamic tables, that would somehow fit the data. I don't know how you are going to manage that, though... can any application make tables that make sense for its problem space? How are those tables partitioned off so that you have some degree of safety, that one application doesn't step on another? How are they then integrated, so information from one application can be used in another?
A non-relational database might make more sense, I believe they are often called Object Databases (not to be confused with an OO RDBMS). That's really just a way of saying "orthogonal persistence", except maybe that they aren't completely orthogonal (they require some extra programming to use).
The problem with orthogonal persistence, that I see, is all the junk that can collect. Having used Squeak, which offers a certain sort of persistence in its images, transient objects can pile up fairly easily and lead to a sort of faux-memory-leak in the system. It's a convenient system, but not stable.
Serialization provides a certain discipline -- it's like you have a checkpoint in the application when everything gets consolodated into something well-defined and granular.
Now, you don't have to serialize to apply this sort of discipline. But orthogonal persistence just makes it so damn easy to be undisciplined. I feel like there's some major work to be done to find a way to manage such a large collection of interrelated objects with indefinite lifespans.
(1) Take a good look at the credits and people behind an open-source project. Pick out those whom you think are
the most involved. Send them RFPs.
I think it would be easier and better to just ask the lead developer (or two) if they'd recommend anyone. They know who is a good contributor, and there's a good chance they also know who's looking for that sort of work.
Of course, if the main developer is looking for that sort of work they might snatch it up without recommending other viable competitors. But really, that's not all that unfair, and a successful leader would hopefully understand the benefit of building good karma.
When any one person does a crime, then sure, blame it on the person. But the US has the largest per-capita prison population in the world, and that's not because the luck of the die has led to a bunch of bad people to coincidentally be born here. It's because something is wrong with this country. The people of the US -- presumably you are also one of them -- have to take responsibility for that.
I don't see how. Yes it is our society and we made it. But we made it give free primary and secondary education to
everyone, and we made it provide welfare to those who need it. There is no excuse for criminal behavior, and
especially no excuse for violent criminal behavior.
The difference is I don't think there's any excuse for society either. There's enough blame to spread it around pretty thick on us all. When all you do is punish, you accept none of the blame for yourself. That is not just.
If you are angry about all the money going to the prison system, then, by all means I agree with you. It's horrible, a waste of money only matched by the incredible amounts of money we waste on the military. We could do truly great things with those resources. But we don't.
However, I don't think you should blame the prisoners for this. They most certainly did not choose to go to jail. Someone else chose it for them.
You could argue that they implicitly chose it for themselves when they committed the crime. But when you consider that most of them are there for nonviolent crimes, at some point we should consider why the law is criminalizing so many people. Any one person may be responsible for their actions, but when you look at the larger picture we are all responsible -- it is our society, we made it, and we as a society should do something about it. Almost no one seems to be willing to do that, though... mostly they just whine and find scape-goats.
The most offensive form of this is people who would have children tried and convicted as adults -- an action that is both absurd and so immoral as to be unforgivable. But that's another issue.
The US has one of the largest per-capita prison populations in the world. Maybe the largest, I can't remember -- I believe with the fall of the USSR and political changes in South Africa, we've been able to move ahead of these paragons of justice to become a truly distinguished nation.
I think there's three possible reasons:
The US just has higher standards -- other nations are willing to put up with more crime and disorder
We unfairly criminalize harmless people, and/or have unfairly long sentences
We have a disfunctional society that creates a disproportionate number of criminals
1 is the only positive reason -- but of course it's also absurd. Both 2 and 3 seem more likely to me.
If the prisoners don't deserve to be in prison (or at least not for as long as they are put there), then they do deserve an education. It's the least we can do for them, even if it doesn't make up for the injustice done on them.
If the prisoners are products of society, then we (as a society) would be well served to try to reform them, simply because it is incredibly expensive to keep someone in jail and because even in jail they will often cause instability in society -- prisoners will often still have friends, family, and children whose lives are disrupted.
LBX seems to address the problems of a thin pipe, not a long one. Compression doesn't do much to improve latency, and a chatty protocol is more limited by latency than bandwidth.
That's where you can use something like GGI as an abstract library over either backend. Other infrastructure, like GTK or QT, could also be ported to both backends.
Re:Emacs Turned Me Into a Real Programmer
on
GNU Emacs 21
·
· Score: 2
Ditto. I use vi whenever i just want to browse a file, or make some minor changes to a file, or createa 4
liner shell script, while I happen to be in the same directory. For any serious programming I use emacs.
Like most, I don't use Emacs to edit config files as root or anything. But I also can't stand vi. I'd highly recommend Zile, which acts a lot like Emacs (at least keybindings) and is very small. Development has restarted on it, and it works quite nicely -- much better than jove or any of the other Emacs-clones I've used.
While there's obviously more ways to use a domain name than just a website, in most cases where there are no websites there is nothing else either. Personally, people who sit on domain names without using them piss me off. There's way to many unutilized domains out there.
The DNS namespace belongs to the public. IMHO, people who use up names without legitimate cause don't deserve to have those public resources.
free != free: there's still support. who do you call when you can't get staroffice to stop crashing?
microsoft will always have much better (and more expenseive, but that's their game) support than
some oss alternative. the support business model is causing small oss vendors to crater left and right.
Not true at all. You can get good support for OSS products -- either with support contracts, or if you have more load, you can hire a consultant. A consultant has a lot more motivation to provide good support, because if they don't you can just hire another one.
Right now most support for MS products isn't from MS by a long shot -- it's by the tech support guy. OSS often requires more advanced support, but the potential capabilities of that support person are considerably greater. As OSS products become more shrinkwrapped even less skilled tech support people will be able to support them. Linux is certainly easier to support now than it was a few years ago.
And please, when was the last time you got support from MS because Office kept crashing? You just reinstall the damned OS and pray.
Unfortunately, unless you are selling goods in a very straight-forward way, e-commerce also includes content management, which is not a Solved Problem.
If you are just selling products in a plain way, you can get simple enough e-commerce. But if you want to provide good e-commerce that ties in with other content, again there are no out-of-the-box solutions. Also, you have to be happy with a out-of-the-box appearance, where you get to control a few graphics and colors on the page, but the essential layout is fixed. It's usually (but not always) pretty easy to change layout -- but that's still not really out-of-the-box.
Well, there's a vague distinction between truly compiled languages and interpreted languages. Almost every language being written right now uses byte compiling -- straight interpretation is very uncommon these days. Compiling to C or machine code is just another step in that direction -- but the distinction is more quantitative (degree of compilation) than qualitative.
All the more reason intellegent computer scientists won't be biased against Interpreted languages.
If you're problem is even moderately interesting, there will be no out-of-the-box solutions. That Open Source might require more implementation time may be true, but the "turn-key" fantasy is most always a lie.
Instead of straight Python with mod_python, you may wish to consider Webware or SkunkWeb, which are both application servers for Python (it ain't all Zope!)
I use Webware myself, and quite like it. Similar to Java Servlets, without the verbose language. I haven't used SkunkWeb myself, but it looks reasonably mature (it's at v3, where Webware hasn't quite reached 1.0 yet... but that doesn't necessarily mean much).
Perl [and other interpreted languages] are looked down upon by CS folk
Don't be silly -- CS folk like interpreted languages. Good, wholesome languages like Scheme, Smalltalk, Prolog... sure they don't like Perl, but don't blame it on the fact it is interpreted. Blame it on the fact that Perl is the antithesis of formalism.
I can't say I agree that JSP, ASP, PHP, or any of the *SP family of languages are good design. They encourage exactly the opposite of MVC, they encourage you to mix HTML and (non-display related) programming code.
This leads to a total mess, and even when the mess is kept under control it's usually with lame templating techniques like having a standard header and footer, which are initially expedient but not very flexible. "Initially expedient" is exactly what the *SP languages achieve, but at the price of later ease of development.
Of course, you can use any of those languages with a <% at the top of the file, and %> at the bottom, with an entirely seperate templating solution, but that kind of renders the whole point of those implementations moot. In my own experience with PHP, my code has started as normal, mixed-HTML/PHP code, and eventually ended up as just one chunk of PHP code.
I've been hit with this. So what do I use to do port forwarding? Is there a daemon that will forward things from one port to another? A quick pointer would help me a ton.
Slashdot Mirror
At least, that is what everything I have ever read or heard implies.
By very careful development, the kernel has been made very stable. However, applications are far from that stable. So when I say that practice needs to be improved, I mean that the correctness of the kernel has to be extended to the system as a whole. Or some other technique of partitioning has to be created, because the partitioning we use in Unix (processes) is part of what orthogonal persistence seeks to eliminate.
Also, garbage collection on a few gigs of interrelated data isn't easy. Single-pass definitely won't work, but there are a lot of good incremental garbage collection algorithms.
Current theory can mostly deal with a large number of persistant objects -- though in many areas it's just theory. Current practice definitely can't deal with this sort of persistance.
"Serialization" means you take your object and turn it into a stream of bytes of some sort. Some more introspective languages, like Python, Smalltalk, and Java allow very easy serialization, but in something like C you spend a lot of time figuring out how to do it. Even if it is indirect, most files somehow represent an object that was in memory and can be put back into memory at a later time.
"Orthogonal" means that something is seperate from something else -- or more specifically, that while two aspects of a thing are related, you can work with one without effecting the other. Kind of -- it's a subtle (though very useful) notion.
"Orthogonal Peristence" means that all objects persist indefinitely with no effort from the programmer. "Orthogonal" refers to the fact that the persistence happens without any relation to other aspects of the program -- everything just persists by default. While it may involve serialization, this is hidden from the programmer, as is any other technique that supplies the persistance.
In such a system there wouldn't be any distinction between objects in RAM or on a disk -- often that is then expanded to objects that are also remote (similar to CORBA, but again, the network access is orthogonal and invisible). Anyway, the system moves things to disk as it needs to, and pulls them off as needed.
I brought up the cleanliness issue before, but the other issue is scaling. Particularly something like garbage collection is a bit difficult, because you can't just do a mark-and-sweep every so often, because anything on the entire disk could contain a reference.
EROS has this, Smalltalks have generally had this (you might wish to look at Squeak), and the old Lisp machines also tended to have orthogonal persistence.
The other option is a database with dynamic tables, that would somehow fit the data. I don't know how you are going to manage that, though... can any application make tables that make sense for its problem space? How are those tables partitioned off so that you have some degree of safety, that one application doesn't step on another? How are they then integrated, so information from one application can be used in another?
A non-relational database might make more sense, I believe they are often called Object Databases (not to be confused with an OO RDBMS). That's really just a way of saying "orthogonal persistence", except maybe that they aren't completely orthogonal (they require some extra programming to use).
The problem with orthogonal persistence, that I see, is all the junk that can collect. Having used Squeak, which offers a certain sort of persistence in its images, transient objects can pile up fairly easily and lead to a sort of faux-memory-leak in the system. It's a convenient system, but not stable.
Serialization provides a certain discipline -- it's like you have a checkpoint in the application when everything gets consolodated into something well-defined and granular.
Now, you don't have to serialize to apply this sort of discipline. But orthogonal persistence just makes it so damn easy to be undisciplined. I feel like there's some major work to be done to find a way to manage such a large collection of interrelated objects with indefinite lifespans.
Of course, if the main developer is looking for that sort of work they might snatch it up without recommending other viable competitors. But really, that's not all that unfair, and a successful leader would hopefully understand the benefit of building good karma.
When any one person does a crime, then sure, blame it on the person. But the US has the largest per-capita prison population in the world, and that's not because the luck of the die has led to a bunch of bad people to coincidentally be born here. It's because something is wrong with this country. The people of the US -- presumably you are also one of them -- have to take responsibility for that.
However, I don't think you should blame the prisoners for this. They most certainly did not choose to go to jail. Someone else chose it for them.
You could argue that they implicitly chose it for themselves when they committed the crime. But when you consider that most of them are there for nonviolent crimes, at some point we should consider why the law is criminalizing so many people. Any one person may be responsible for their actions, but when you look at the larger picture we are all responsible -- it is our society, we made it, and we as a society should do something about it. Almost no one seems to be willing to do that, though... mostly they just whine and find scape-goats.
The most offensive form of this is people who would have children tried and convicted as adults -- an action that is both absurd and so immoral as to be unforgivable. But that's another issue.
I think there's three possible reasons:
- The US just has higher standards -- other nations are willing to put up with more crime and disorder
- We unfairly criminalize harmless people, and/or have unfairly long sentences
- We have a disfunctional society that creates a disproportionate number of criminals
1 is the only positive reason -- but of course it's also absurd. Both 2 and 3 seem more likely to me.If the prisoners don't deserve to be in prison (or at least not for as long as they are put there), then they do deserve an education. It's the least we can do for them, even if it doesn't make up for the injustice done on them.
If the prisoners are products of society, then we (as a society) would be well served to try to reform them, simply because it is incredibly expensive to keep someone in jail and because even in jail they will often cause instability in society -- prisoners will often still have friends, family, and children whose lives are disrupted.
LBX seems to address the problems of a thin pipe, not a long one. Compression doesn't do much to improve latency, and a chatty protocol is more limited by latency than bandwidth.
That's where you can use something like GGI as an abstract library over either backend. Other infrastructure, like GTK or QT, could also be ported to both backends.
The DNS namespace belongs to the public. IMHO, people who use up names without legitimate cause don't deserve to have those public resources.
You can get a very cheap refurbished computer at Comp-Geeks. I've had very bad luck with the monitors, but the other hardware has been fine.
Right now most support for MS products isn't from MS by a long shot -- it's by the tech support guy. OSS often requires more advanced support, but the potential capabilities of that support person are considerably greater. As OSS products become more shrinkwrapped even less skilled tech support people will be able to support them. Linux is certainly easier to support now than it was a few years ago.
And please, when was the last time you got support from MS because Office kept crashing? You just reinstall the damned OS and pray.
If you are just selling products in a plain way, you can get simple enough e-commerce. But if you want to provide good e-commerce that ties in with other content, again there are no out-of-the-box solutions. Also, you have to be happy with a out-of-the-box appearance, where you get to control a few graphics and colors on the page, but the essential layout is fixed. It's usually (but not always) pretty easy to change layout -- but that's still not really out-of-the-box.
All the more reason intellegent computer scientists won't be biased against Interpreted languages.
If you're problem is even moderately interesting, there will be no out-of-the-box solutions. That Open Source might require more implementation time may be true, but the "turn-key" fantasy is most always a lie.
I use Webware myself, and quite like it. Similar to Java Servlets, without the verbose language. I haven't used SkunkWeb myself, but it looks reasonably mature (it's at v3, where Webware hasn't quite reached 1.0 yet... but that doesn't necessarily mean much).
This leads to a total mess, and even when the mess is kept under control it's usually with lame templating techniques like having a standard header and footer, which are initially expedient but not very flexible. "Initially expedient" is exactly what the *SP languages achieve, but at the price of later ease of development.
Of course, you can use any of those languages with a <% at the top of the file, and %> at the bottom, with an entirely seperate templating solution, but that kind of renders the whole point of those implementations moot. In my own experience with PHP, my code has started as normal, mixed-HTML/PHP code, and eventually ended up as just one chunk of PHP code.
I've been hit with this. So what do I use to do port forwarding? Is there a daemon that will forward things from one port to another? A quick pointer would help me a ton.
I meant "America" in the most generic fashion, though I suppose that wasn't clear.