You don't get more pixels. In some cases you get *less*!
That's exactly my point. I don't care if it's delivered anologously or digitally, I only care about how many pixels I get. I don't care about the underlying technology, as long as it brings me the quality I want (in the case of TV only, of course).
Maybe I am even against the the introduction of digital TV atm. We had better skiped that step, and went directly to HDTV, instead of letting the consumers buy new hardware, only to let them know that a few years later, they had to purchase new hardware again to make the transition to HDTV. Of course, to have an electronic progamming guide etc. is nice, but the thing which bugs me most is the bad resolution paired with bad image quality (some broadcasts even look like those stamp format movies viewed in full screen mode).
Though I know there may be folks outthere which in turn don't give a sh*t about image quality, but hey, this is just me.
If it finds a way to escalate privileges to admin or root, it can do whatever it wants. Most of the times, the application which allows for remote exploitation does not have superuser privileges. But the attacker can then go on and use a program which is vulnerable to a local attack, and there's a probability that there is also some suid root program on the machine.
The probability is approx. 1 that I was asleep then.
Oh, and btw., if you're into quality dreaming, nothing beats a good lecture about polynomial fitting. Gives really nice templates for upcoming fancies! And not to forget finding tightest circles around point clouds. Mmmhhh! Especially if there are two independent clouds in the graph.
In his second and most popular work, The Golden Ratio, he chose to write about the number Phi. The book reads like the front page of Slashdot, skipping quickly from topic to topic, though sticking to the general theme, insuring that the reader must never get bored.
Cool, the first book with dupes already integrated!!
I personally think that transparency is one of the key principles. Use a central repository where everyone can look at each others' code, use a central bug tracking facility, and call people by name who checked in code which broke things (something which e.g. XP proposes). With that you can ensure that people are aware of their responsibility for things they did, and others know whom to contact if the breakage was intended and they needed to adjust their own modules.
If you have a tool which integrates all this into a single workflow, the better (e.g. Eclipse with Bugzilla plug-in, etc.).
Of course, if you only have one person per project and you're not planning to change this scheme in near future, you can save yourself some of the overhead.
if x==456 then//checks for conditional x and executes code if x is true
- this is not a good comment
if x==456 then//checks to see if x is equal to 456. If it is, then the code within is executed
-this is a good, easy to understand comment.
Is this supposed to be a joke??! Both of them are worst comments, because they only formulate in english what the code already says by itself. Everyone can see that this is an if-statement, everyone is able to identify the condition, and everyone knows the semantics of an if-statement.
A good comment is not describing what is done (since everybody can see that from the code itself), a good comment describes why something is done, or what the overall objective of the statement is.
For example:
if (x == 456) {// Check if step motor reached final position. If yes, halt motor, otherwise step forward.
This is ways more useful. Even more useful would be to already use self-describing symbol names in the code itself, like
Depends on who has the burden of proof in such cases. If an EULA is handled like a regular contract, at least in my country, the party which makes the claim also carries the burden of proof.
Obviously *nix is a much more difficult problem for them to deal with... but you're just asking for it by sitting around lazily thinking it could never happen to you.
Even if that day arrives, it's still a user problem, and can hardly be solved by software, apart from not running anything without the user's consent, sandboxing, and maybe trying to analyse the expected behaviour of the software to run.
Unix already does the job of inhibiting software from automatically running, or doing bad things. If you have more ideas to protect the user from malware, then make them public.
Well, one genuine story per week is enough for that purpose. Thanks to the slashdot autodupe feature, it is then being reposted the 6 following days, with slightly varied titles.
Yes, it looks like they're simply ignoring us. This is so unfair! I am still awaiting the day where I can laugh my ass of about some sony sillyware trying to run its IA32 binary on a mips.
I think this is a normal price tag for such tools...;) For ClearNova ThinkCAP you're going to pay 2'500 USD for the workbench, and the server edition costs you 15'000 USD. Morfik does not even have pricing information yet at all.
Backbase does though have a so called community edition, which is free of charge for non commercial purposes.*
* I am in no way affiliated with backbase, nor have I tried or used a single product of them!
Who exactly is the group that is going around saying, "Buy brand X car, you can modify it any way you like"? None that I'm aware of. So no one ever has those expectations in the car world. There is no such thing as a car that exists in open-source and commercially-supported versions, though, so the analogy doesn't hold up that well.
Hmm, I do not completely agree here. Fact is, that you can modify your car however you like, from the first day on (as long as it is kept within the legal limits). But nobody expects their dealer to fix it then within normal contract. I even dare to call a car a partial open source commodity (you can modify it however you like, and the "source" of many parts of a car is open, or you can at least discover the "source" by e.g. taking the gear box apart).
Further, it is true that you can modify your FL/OSS software however you like, that's what the/. crowd tells everyone, and that's what e.g. RedHat tells it's customers. The difference with closed software is that you can take the product you bought from RedHat, and change it to your liking at source level. You can't do that with MS Office. That's the point. But claiming companies like RedHat would be dishonest to their customers because they do not support customer-modified software out of a normal service contract is a bit far fetched.
The freedom to modify software at source level and service contracts are two different things, and are also marketed as such, and I think that normal customers with some business experience are able to tell that difference, and can derive by themselves that changing the product makes it your own product, and not that of RedHat anymore, and therefore disqualifies it for regular product support.
What you and MS claim is that normal customers are unable to tell this difference, and RedHat et al. should print a warning on their boxes to make this clear. This somehow reminds me of microwave manufacturers which have to warn their customers to not put their dog into their product, because otherwise the manufacturer would be liable for not having their customer told so. This is stupid because, even if we made a closed world assumption, it wouldn't be practical nor possible to list all things you must not do with your microwave, or all things which are not possible with a software service contract. I feel that customers are mature enough to be able to derive the correct meaning of positive statements, not needing every possible negative statement just to derive the proper set of claims. (On a sidenote, this seems to be a phenomenon limited to the US of A only, since I yet have to find a manufacturer over here in Europe which has to list all things you mustn't do with their products.)
[1] I don't know, maybe the ISVs do have some clause about it in their service agreements or some such, but you don't see that until you're well into the process, having at least selected Red Hat or whoever as a major contender.
I hope people are educated enough to read their service contracts before they sign them.
People get Open Source marketed at them (by the/. crowd) with promises of being able to modify whatever they need to. Then, when they say, "all right, I'm in", they get ushered over to Red Hat (two words -- even the Slashdot editors spelled it right!) to sign up for support. Surprise, surprise, no one told them to give up their notions of modify-it-yourself that sold them early on. Sure, if you think about it, it's kind of stupid to expect both. But it's not human nature, and not that easy, either, to constantly check new facts against previously received ones, and we're sort of putting out a contradictory message, like the car ads where they'll list the fuel economy and base price of the 4-cylinder model, but the 0-60 time of the 6-cylinder turbocharged model. Not exactly honest.
So, to stick with the car analogies, you expect your car dealer to fix your car if it breaks within guarantee, although you've modified the motor, and exchanged the breaks. All at no cost extra.
Sorry, but this is plain stupid. It does not work like that in non-FL/OSS industry, and noone claims that it works like that with FL/OSS. You just can't buy a service contract, do whatever the heck you like to the software, and then expect them to support your own code without giving them extra money for the time they need to analyse the changes you made to their software.
Slashdot Mirror
That's exactly my point. I don't care if it's delivered anologously or digitally, I only care about how many pixels I get. I don't care about the underlying technology, as long as it brings me the quality I want (in the case of TV only, of course).
Maybe I am even against the the introduction of digital TV atm. We had better skiped that step, and went directly to HDTV, instead of letting the consumers buy new hardware, only to let them know that a few years later, they had to purchase new hardware again to make the transition to HDTV. Of course, to have an electronic progamming guide etc. is nice, but the thing which bugs me most is the bad resolution paired with bad image quality (some broadcasts even look like those stamp format movies viewed in full screen mode).
Though I know there may be folks outthere which in turn don't give a sh*t about image quality, but hey, this is just me.
Therefore:
Fucking lameness filter!!Oh, and btw., if you're into quality dreaming, nothing beats a good lecture about polynomial fitting. Gives really nice templates for upcoming fancies! And not to forget finding tightest circles around point clouds. Mmmhhh! Especially if there are two independent clouds in the graph.
Cool, the first book with dupes already integrated!!
The only good thing about it were the justification to leave the workplace every 10 minutes. "Oh, hi boss, sorry, it's advert break again!".
Pretty neat list.
I personally think that transparency is one of the key principles. Use a central repository where everyone can look at each others' code, use a central bug tracking facility, and call people by name who checked in code which broke things (something which e.g. XP proposes). With that you can ensure that people are aware of their responsibility for things they did, and others know whom to contact if the breakage was intended and they needed to adjust their own modules.
If you have a tool which integrates all this into a single workflow, the better (e.g. Eclipse with Bugzilla plug-in, etc.).
Of course, if you only have one person per project and you're not planning to change this scheme in near future, you can save yourself some of the overhead.
Is this supposed to be a joke??! Both of them are worst comments, because they only formulate in english what the code already says by itself. Everyone can see that this is an if-statement, everyone is able to identify the condition, and everyone knows the semantics of an if-statement.
A good comment is not describing what is done (since everybody can see that from the code itself), a good comment describes why something is done, or what the overall objective of the statement is.
For example:
This is ways more useful. Even more useful would be to already use self-describing symbol names in the code itself, like
Depends on how judges of future cases interpret the finding of this case.
Even if that day arrives, it's still a user problem, and can hardly be solved by software, apart from not running anything without the user's consent, sandboxing, and maybe trying to analyse the expected behaviour of the software to run.
Unix already does the job of inhibiting software from automatically running, or doing bad things. If you have more ideas to protect the user from malware, then make them public.
Well, one genuine story per week is enough for that purpose. Thanks to the slashdot autodupe feature, it is then being reposted the 6 following days, with slightly varied titles.
Await next Sony story anytime now.
Backbase does though have a so called community edition, which is free of charge for non commercial purposes.*
* I am in no way affiliated with backbase, nor have I tried or used a single product of them!
Hmm, I do not completely agree here. Fact is, that you can modify your car however you like, from the first day on (as long as it is kept within the legal limits). But nobody expects their dealer to fix it then within normal contract. I even dare to call a car a partial open source commodity (you can modify it however you like, and the "source" of many parts of a car is open, or you can at least discover the "source" by e.g. taking the gear box apart).
Further, it is true that you can modify your FL/OSS software however you like, that's what the /. crowd tells everyone, and that's what e.g. RedHat tells it's customers. The difference with closed software is that you can take the product you bought from RedHat, and change it to your liking at source level. You can't do that with MS Office. That's the point. But claiming companies like RedHat would be dishonest to their customers because they do not support customer-modified software out of a normal service contract is a bit far fetched.
The freedom to modify software at source level and service contracts are two different things, and are also marketed as such, and I think that normal customers with some business experience are able to tell that difference, and can derive by themselves that changing the product makes it your own product, and not that of RedHat anymore, and therefore disqualifies it for regular product support.
What you and MS claim is that normal customers are unable to tell this difference, and RedHat et al. should print a warning on their boxes to make this clear. This somehow reminds me of microwave manufacturers which have to warn their customers to not put their dog into their product, because otherwise the manufacturer would be liable for not having their customer told so. This is stupid because, even if we made a closed world assumption, it wouldn't be practical nor possible to list all things you must not do with your microwave, or all things which are not possible with a software service contract. I feel that customers are mature enough to be able to derive the correct meaning of positive statements, not needing every possible negative statement just to derive the proper set of claims. (On a sidenote, this seems to be a phenomenon limited to the US of A only, since I yet have to find a manufacturer over here in Europe which has to list all things you mustn't do with their products.)
I hope people are educated enough to read their service contracts before they sign them.
So, to stick with the car analogies, you expect your car dealer to fix your car if it breaks within guarantee, although you've modified the motor, and exchanged the breaks. All at no cost extra.
Sorry, but this is plain stupid. It does not work like that in non-FL/OSS industry, and noone claims that it works like that with FL/OSS. You just can't buy a service contract, do whatever the heck you like to the software, and then expect them to support your own code without giving them extra money for the time they need to analyse the changes you made to their software.
So please stop making such braindead comments.