They also made the surround on the Tab darker to make it look more like the iPad. Submitting photoshoped images to the court should cost them their case.
Not to mention that the "evidence" shows the Galaxy Tab in a vertical position when the default/intended usage is in a horizontal position.
... and so on and so on. In fact, IIRC, its predecessors have always been marketed in a default horizontal position, and that's how I've always seen it display at Costco and at tmobile (my cell phone provider).
Call me conspiracy theorist, but this cannot be by accident. Morphed dimensions by itself an accident? Maybe (and that's pushing it). Shown in a vertical position as opposed to the horizontal position it is shown everywhere else as an accident? Maybe. But both, as legal evidence? Got to have been done on purpose.
A less than 7% change in the aspect ratio is negligible. And they're complaining about the size of a picture too? Good grief. The point is how similar the products look to consumers. Of course it's best to have things displayed at the same size to best see similarities in the design, any border width, curvature of corners etc.
If someone wants to fuss about small differences in size, please do something about those containers of ice cream that aren't a half-gallon any more. That's a crime against humanity!
Just because it is negligible to you that does not imply it is negligible to the case (after all, Apple claimed that they are "practically identical".) Considering the difference in aspect ratio, and the fact that the wrong evidence shows the Galaxy Tab in a vertical position (as opposed to the horizontal which is the default), then you see that there is a problem with the evidence presented to the judge as proof that these two products are "practically identical".
Whether you think that's a fuzz about nothing, that's as irrelevant as unquantifiable personal opinions go in a court of law.
Naturally a city with such a good infrastructure would also have plentiful fire hydrants.
Since that's the only fire rescuing infrastructure one would require in a city of significant size. Not to mention all the other infrastructure requirements for such type of population centers.
Slashdot posters can't seem to imagine anything but the suburban wastelands they live in.
Just because you imagine it does not translates it to the realm of the practical (or even efficient). There are a lot of ways to design civil infrastructure that is more eco-friendly, economical and sustainable. Yours ain't one of them. You haven't even put any thought behind them as you are simply defending the indefensible just as a matter of course. It is crap like this that gives sustainable engineering a bad rep among the common cattle. Despite what you might believe about yourself and your ideas, you are also part of the same mindless cattle (but just so happen to be munching grass on the other side of the corral.)
Also, a tendency to making derogatory assumptions (and that are easily falsifiable) on the readers that disagree is usually an indication that a logically weak point is being defended. But don't let that dissuade your exercising of your freedom of speech when making dumb posts and all that. So feel free to build up your strawmen, so long as you don't complain about the splinters you get from f* with it.
A forklift can tow water pumps, tanks, and other equipment without any trouble.
Ever drove one? I have, for work, and for years (when I was working full-time while getting my BS degree in CS.) They are great for lifting things up and down, but you have to drive them in reverse for safety (unless you drive the small types), they are designed for carrying things on their forks, not for hauling (very important distinction, just look at their wheels for Christ's sake), and I believe (I could be wrong in this) they are not designed for efficient traveling over the same distances you would expect a firefighter truck to do (not to mention they cannot sustain the same type of speed a truck would.)
Granted, my experience with forklifts and similar equipment has been limited to their typical usage in warehouses (lifting heavy shit and move it from a warehouse/container to/from a transport/another container.) But based on my work experience alone, I do not believe what you are proposing is viable.
Tear up half the road and use it for rail and the remaining half for bikes and pedestrians. Also, allow freight via light rail to eliminate the need for delivery trucks in the city.
How do emergency services operate?
They don't. People are self-reliant, are one with nature and all that kumaya shit.
"When the bomb absolutely has to be anywhere in the world in 30 minutes or less, DARPA is there!"
Where do you need to go that fast? Why do you need microwaves? Why do you need a protocol that allows people to send data over an unreliable network? Why do we need all of this?
I haven't read it either, but I think it should probably be overturned unless there's evidence for the extortion charge other than just doing a lot of it at once.
Extortion is about threatening harm to someone to get something you aren't owed. That's certainly a reasonable charge if I threaten to sue someone who doesn't owe me anything and I offer to take a small sum of cash rather than put them through the cost of a trial.
But if I own a patent and I see others selling products containing that idea, I'm owed royalties. The fact that there are a lot of infringers and I'm willing to settle immediately instead of demanding more and insisting on going to court to get it means I'm the good guy in the situation.
It's all about whether my case had merit. Maybe this guy's case didn't, for most of his targets.
But that is what's in the court's findings according to TFA. The lawsuit was without merit, and the plaintiff was not found to have broken any copyright laws. Ergo he owns nothing to the patent troll. Ergo, patent troll was trying to get something that he didn't own off the plaintiff. Furthermore, the court found that this was ample evidence that this was the patent troll's modus operandi. Ergo, patent troll has attempted to seize something he didn't own from other plaintiffs using similar, merit-less lawsuits.
Patent troll might have owned the patent, but the plaintiff didn't break it, and since the patent troll not only did not due due diligence as found by the court, the court itself found that patent troll has not done any due diligence at all when filing the hundreds of similar lawsuits. It is hard to argue, logically and legally, that this is not a systematic attempt at extortion not just against this specific plaintiff, but against many others (independently of whether patent troll owns the patents or not.)
While I don't disagree that spending must be cut, the problem with the majority of people and politicians who talk about spending cuts never seem to include military spending. Funny, that.
What are you talking about? There have been cuts on the military to the left and right.
Color me surprised that the Government sides in its own favor in its own cases.
I'd actually go out of a limb and suggest that maybe this below is a the root of the decision, not a by-default mechanism to judge to the government's favor (feel free to argue that this is not the case):
The main purpose of the Rojadirecta websites, however, is to catalog links to the copyrighted athletic events — any argument to the contrary is clearly disingenuous.'
Also, there have been numerous occasions where the supreme court has ruled against the government. But don't let these details bother you (after all, YOU know that is is true, and yet you wish to ignore it in order to make such a silly statement.)
The Java VM is a very poor abstraction for most underlying hardware. I think a general purpose IM would be a much better idea.
You know that the Java VM is not an abstraction for most underlying hardware, don't you. As I mentioned in my prev. post, it is an operating environment for a specific class of problems which provides a slew of app-specific services that are not necessarily general purpose. IM servers one type of purposes, VMs serve others.
Also, I know that you think like that. However, I *think* you need to qualify your stated opinion. Without it, it is as valuable as saying "I think oranges are better than apples."
I mean seriously, what do you mean by this?
The Java VM is a very poor abstraction for most underlying hardware.
Why? How? Under what conditions? More importantly, is that the JVM's objective? (hint: it isn't)
And and what to you mean by this?
I think a general purpose IM would be a much better idea.
Why? How? Under what circumstances? And if IM is a better alternative, how is it to implement the configurable gc logic, the class loading logic, the JMX and other management extension logic, the security manager logic, the reflection logic, the JNDI logic, the JDBC logic, all the specs that come with it (all of which are defined as universal standards for that application stack)?
Obviously it would have to be deployed in the OS as a shared library, and then you'll have to ask you why is that a better deployment/distribution model over the JVM, how and under what conditions.
Without that, all you are saying is that *you like* apples more than oranges. Not much helpful, isn't?
I've never understood why a virtual machine is, in any way, better than an intermediate language that can be compiled to native code for a particular platform.
For the same reason that in many platforms (x86 for instance), your compiled code gets compiled to high level instructions and not directly into microcode. In the same way that the x86 instruction set insulates you from possible chip architectural changes (that could change the underlying microcode), so does software-level vm instruction sets. The later provides you with a higher level of abstraction to work on, tends to simplify things, and provides a good-enough degree (but a 100% one) on portability across machine architectures.
An interpreted language may make sense for dynamically created code.
Java is not an interpreted language. It compiles to JVM byte code with very small resemblance to the original source code. An interpreted language is one that is parsed and, if valid, executed at run time. The adjective 'interpreted' doesn't fit here.
Even so, why not just compile it first?
But you do. You compile it into JVM bytecode. Compilation does not mean absolutely translate into hardware-specific machine instructions.
You can run interpreted code in a sandbox
Or you could run compiled code in a sandbox (pls see previous comment about interpreted vs compiled.)
but any IM compiler could add the same features to native code.
Yes, but then you have to implement back-end native instruction generators for the platforms. OTH, if you provide a VM (not just necessarily a JVM), which itself is compiled to a selected number architectures, and which code and behavior is narrower than the general cases one has to consider otherwise, then you only focus on the issues pertaining to application-specific code compiling to into that VM.
Also, a VM provides higher-level abstractions that make development of apps (and compiler toolchains and introspection tools) easier.
One thing to remember is that a VM (and the JVM in particular) provides another layer of abstraction with services and constrains not necessarily available (nor desirable) at the OS level.
For better or worse, depending on how you want to look at it, the JVM provides a security model, a memory model, a concurrency model, etc. It provides class loading and reloading capabilities, integrity checking of classes before loading, easier mechanisms for bytecode manipulation and reflection (this extremely important for most app-level development), a robust JIT, configurable garbage collection algorithms that you can configure according to the type of hardware you have, and so on and so on.
So the JVM is not just a bytecode interpreter, but an entire operating environment with high-level services targeted for a specific class of problems (and the applications that solves them.) For that type of application development, a VM makes more sense than direct compilation to an architecture instruction set on an executable format that is typically OS-specific.
In all major platforms the JVM runs, not just on x86. Heck, there are high performance platforms out there (Azul comes to mind) that have the JVM, the JIT, the GC and a lot of other things running on the dye.
Methane, Large sources of easily available water, or Oil. One of those three are the most likely.
Considering the focus on geology, it's also possible they've found a surface deposit of some rare earths minerals (such as those which are currently exported only by China), though you're right, methane is probably the most likely, and while geologists studying Mars might find it interesting, it's not nearly as significant to the rest of the human race.
Focus on geology? What else would you expect study of a planet to be focused on? That's what geology is.
Oil? Obviously you must be joking.
Oh, and rare earths aren't; rare earth ores are somewhat more so, but that is more a function of economics than anything else (an ore is an economically recoverable mineral resource; there are ample rare earth mineral resources around Earth, just not generally economic to recover - but that depends entirely on the price). No amount of rare earths on Mars are going to mean anything to anybody in economic terms until long after people are living there, if ever.
That would move people off their asses off to the nearest start, certainly to Mars as well.
The recent unsettling behavior at Microsoft concerning.NET makes it a good time to re-evaluate what the technology is all about. It may have been good technology but with the systems guys building Windows preferring to stick with C++ the outcome was inevitable. Because they failed to support its way of doing things.NET has always been a second class Windows citizen unable to make direct use of the Windows APIs — especially the latest..NET started out as Microsoft's best challenge to Java but now you have to ask what has the excursion into managed code brought the Microsoft programmer and indeed what good has it done Microsoft? From where we are now it begins to look very much like an unnecessary forced detour and Windows programmers are going to be living with the mess for years to come.
There are two, possibly unrelated factors to take into account here: 1) appropriate support for.NET, and 2) the value of managed code.
I would argue that the last thing one wants to do, in general, is to NOT use managed code for application development, in particular application code that is subject to continuous modifications and deployments.
That Windows systems developers prefer to stick to C++ (and actually C as you go deeper), that should not come as a surprise. I would be a surprise if anyone half-literate in software development would think otherwise. I would be more surprised if anyone would expect anyone but a dumb-wit to do low-level systems development with managed code.
So, I don't understand why an understandable preference to do systems development with a systems language (which just so happens to be C or C++, but which could have been Ada or Pascal) would have a detrimental impact on using a managed code platform and stack for the general case of application-level development.
Me no get it. Does not compute.
Moreover, it seems that the author of this piece is conflating issues here. This is what the author seems to be going about:
1. Fact: MS seems to be moving towards JavaScript and HTML5 as the main development stack for application development instead of.NET
2. Fact: System-level Windows programmers use a systems level programming language (C++) for systems-level development.
-----------
Ergo: Oh shit, the later caused the former!(10+1)
Correlation does not mean causation. And in fact, there isn't even a correlation at all. Whether MS drops.NET in favor of HTM5 and JavaScript does not mean anything about MS venturing into managed code land. And I would be hard-pressed to imagine that MS does not have any plans for the significant investment it has made in the.NET platform.
The funniest thing of all is that the author seems to miss this important fact: JavaScript is managed code. So in essence, MS is simply moving from one managed code stack "a" to another managed code stack "b". That's all. Fundamentally, it is just that, a change of managed stacks, a reflection (or adjustment) to the changes, to the paradigm shifts in application delivery. Nothing more.
How a preference for C++ for Windows systems level programming is even in the picture here, it beats the hell out of me.
How is a half-black, half-Latino teenager more politically correct than a white teenager?
I completely agree with this. The change to some sort of racial token guy was a stupid publicity stun. Not to mention that 'half-black, half-Latino' is an oxymoron as there are black Latinos.
What's important in comics (or it should be) is the story and the super hero original character, not a ethnic makeup change. People don't give a rat's ass if he's a dreadlocks-wearing transgender half-mix between Flores Island Hobbits and Druids, raised and fed by Chinese-raised Klingons immigrants the futuristic ghetto of District 9 (although sadly, this is going to be the recipe for the next Twilight Spiderman Xtreme Ultimate, DragonBall-Z-meets-Sailor-Moon edition.)
If you are completely crippled by your tools not being available, you are not "intelligently using tools available."
This is an absolutely true statement... when you take it all by itself, just like saying "the sky is typically blue in the desert". Great, good for you. You are still re-iterating the extreme, negative case on a false dichotomy. You don't prove that a dichotomy exists by reiterating one side of it. You do so by showing that there is nothing in between the extremes. It is not an inevitability to become completely crippled by the tools at your disposal just because of their prevalence.
Many developers are baffled by things like memory management or reference counting, and want the language to figure out when memory is no longer in use
Non-sequitor. What you are describing is a function on the exposure of low-level programming languages, not on the availability of integrated environment tools. I've programmed in C, C++ and Assembly (plus Ada and Pascal where you can still get your SEGFAULTS), and now I'm going to lose proficiency in low-level management crap just because all of the sudden I use Eclipse with a C/C++ plug-in and Valgrind and VectorCast and all other high-level tools? I start working with an integrated development environment for Java enterprise development, and I'm now going to be baffled at the sight of memory management?
There are individuals out there doing app-level development who have not have had any exposure to these kind of things, but to suggest or even believe that such is the general case is such a display in self-congratulatory wishful thinking, it is just ridiculous. Don't delude yourself into thinking that people who do C or C++ fare any better. I've seen code on both sides of the equation. Not pretty.
and garbage collect it because they simply can't wrap their head around the idea of tracking data;
And that shows me you have no clue what you are talking about. You use garbage collection for application-level code, concentrating the tasks of memory book-keeping in a safe, tried-and-true, tested-till-it-bleeds critical section of your infrastructure, based on reliable, robust GC algorithms. Then you put your energy and efforts in developing the algorithms necessary for implementing the app-specific requirements, which, by the very nature, are highly volatile. Direct, manual memory book-keeping has absolutely no place in app-level code (in the same way that runtime type identification and reflection have no place, most of the time, in systems-level code.) Anyone who tries to do otherwise should be fired on the spot.
many others sit down and design a program before writing spaghetti code, and occasionally cause implementation bugs.
Which occurs also among programmers that do C and C++ with nothing but Vim and gcc (and I have the code to prove it.) So what's your point?
While you can be competent and write in Java, you can also turn white at the mention of C (and immediately confuse it with C++)
Well, I don't, and a large number, if not the majority of Java developers with a solid CS degree do not either. Even for a CS graduate who hasn't had work experience in systems level programming and goes straight into application level programming using Java or what not, what on earth do you think CS students do when they do their OS and Unix programming courses?
It is a pervasive fallacy - held by some, God only knows why - based on a morbid exaggeration of an actual problem that manifests itself in many forms across applications and systems programming domains.
and use Java to simulate knowing what in the hell you're doing.
Fair enough, I haven't used it long enough to even be bothered to personalize that. My main question would be WHY are tabs not characters? Why should having to hit backspace 4 times to knock down indentation one level be a default?
Because your default way of doing is highlight/shift+tab? Not counting the fact that auto-indentation in Eclipse is 1) highly configurable (you can tell it to auto-format brackets, spaces and what-not with just a few clicks); 2) it is automatic; and 3) it is very efficient. It ain't rocket science. Well, it might have looked like that back in the day when we had nothing but vim (or ed or some archaic crap like that) over a VT-100 terminal with they keyboard mappings all fucked up. But now, in 2011? I mean, c'mon.
What benefit is there?
Allowing spaces instead of tabs makes sure that the intended visual impact of indentation remains the same (most of the time, but not always), independently of whether you open the source code in VIM, Notepad++, pico/nano, Notepad, Eclipse, NetBeans, JDeveloper. Edge case mind you: sometimes you still have a 120-column dot-matrix printer (which is the best thing for printing reams of code), you cat the code down to that bad boy, and you want the indentation to appear in the printer exactly how they come up in the screen. Typically, you cannot do that if you use tabs.
Unless you are doing JavaScript - where you sometimes have to be mindful of the actual number of bytes being send down the wire - this is a non-issue. And even with JavaScript, one can always maintain the source code indented in any specific way, with the.js files being passed through a "compactor" before being deployed or sent to the client's browser.
It is really a non-issue. No, really, seriously. At most, it is a mild annoyance of no significant consequence.
would love to have worked with this guy during the 2009 uprising. He has a point, those twitter revolutionaries will behave "better" ("better" as defined by the old guard) would they have used their real names.
Yeah, I was too vague when I said that. The integration in Eclipse is well done. Eclipse itself (editing) is awful. Things like Eclipse automatically adding random lines (like imports) whenever I copy and paste between files? Yeah, that's a terrible feature. Panes/splitting and pane management is very obscure as well. Oh, and tabs are characters, not 4 spaces - seriously fucking stop with the tab conversion.
C'mon man, this is 2011.
1. Window/Preferences/Editors/Text Editors/Insert spaces for tab (uncheck)
2. Windows/Preferences/Java/Code Style/Formatter/Active Profiler/Edit/Indentation Tab/Tab Policy: Use spaces to indent wrapped lines (uncheck)
You find those two in a most trivial manner. JFGI Eclipse style. Simply enter "tab" in the search box in the Windows/Preference window, and voila, it shows you how to control tab expansion. This is a capability present in any modern IDE or code editor. It is something trivial that one should reasonably expect any developer to figure it out rather quickly.
There are a lot of challenging things in software. This ain't one of them.
Some of us juggle all that stuff in our heads and have a complete map of our code, which becomes difficult to track when we have to deal with automagic shit or go make amendments or deletions from one side or the other.
There is no automagic. There never is. There are IDE-assisted automatic features (the majority of which is useful), the configuration and behavior of which are not rocket science, and which we either understand or we do not.
Others write bits of business logic and string it together, and hope it works; often these people rely on development environments to take care of some of the stringing together.
False dichotomy between the previous case and the later ones. It might surprise to some, there is people out there who understand the code and intelligently use automated tools for integrating it. We don't get paid to show off our l33t hax0r skills, but to intelligently use tools available for coding to our employer's benefit.
I will also argue, and there is plenty of evidence of it, that, unless you are an absolute genius, if you can completely map the code out in your brain, the complexity (not necessarily the size) of that code is trivial, or small-sized at best. Some languages (say Ruby or Python) are better than others (Java, C++) for helping the developer write more succinct, mentally-manageable code. But beyond a certain size and complexity, independently of whether it is systems or application development, one simply cannot claim to mentally map the code (unless you are the owner of a module and you are actively maintaining it.)
Also, it is a false dichotomy to present business logic and code as separate entities. Business logic gets implemented on code, on top of other non-functional requirements. Code is the executable representation of business logic, it is knowledge captured and codified in software. Break that relationship, and all you have is code for shit. Business logic changes constantly causing inevitable code/system changes and increasing entropy (yes, the 2nd law of thermodynamics applies to software).
It is our job to put constant effort in controlling/negating entropy in the affected systems. And that's what integrated environments are for, to provide for automated tools that when used intelligently in conjunction with good programming practices helps with that part of the software development cycle. These are just tools and they perform according to the hand that wields them. This is something that is sadly neglected or considered irrelevant or trivial.
I've seen these type of claims before, and I'm compelled to ask you. Why do you do it?
Yeah, I was too vague when I said that. The integration in Eclipse is well done. Eclipse itself (editing) is awful. Things like Eclipse automatically adding random lines (like imports) whenever I copy and paste between files?
If by "random" you mean the actual imports needed for the things you copy and paste...
... I mean, seriously. The only time you should ever see an unexpected (not random as there is nothing random going on here, but unexpected), it is because you failed to set up the class path with the correct jars in your project or IDE setup. As a result, Eclipse via reflection picks the first class off the class path that matches the name of it (not the one you want.) And that would be a problem between the keyboard and the chair, not the IDE. I mean, who the heck does Java development w/o setting up a clean class path?
Yeah, that's a terrible feature.
No, it is a problem between the keyboard and the chair.
Panes/splitting and pane management is very obscure as well.
Exactly how? It ain't rocket science. I'm really honest about this.
Oh, and tabs are characters, not 4 spaces - seriously fucking stop with the tab conversion.
Wow, just absolutely wow.
Dude, just do the following:
-- Window/Preferences/General/Editors/Text Editors/(Uncheck)Insert spaces for tabs
-- Java/Code Style/Formatter/Edit Active Profile/Indentation/Tab Policy - Use spaces to indent wrapped lines.
Or simply go to Window/Preferences and type "tab" in the search, and it will show you what settings to change. I can understand a non-technical person not finding a way to change the editor's behavior, but a developer? C'mon. This is like a Winloser saying that gcc on Unix doesn't work because he/she doesn't find a resulting.exe file.
Also, when it comes to tabs over spaces, why would you be so anal about it? It's a freaking config setup, and sometimes, if you work with a team with a retarded set coding standards, they mandate what to use (ergo, not up to you.) And sometimes you inherit code that doesn't necessarily align to your formatting predilections. What do you do then? Do you reformat it all out of the blue? No, you work through. In general, it's a non-issue.
I personally prefer spaces over tabs anyways because I know that the original indentation (which is very important to me) will remain the same independently of whether I open the source code with Eclipse or Vim or Notepad. But that's just me.
For record I used vim for the longest time (funnily I switched from Emacs to Vim), then briefly used JEdit and JDeveloper, picking up Eclipse just recently (back in 2007). I've never had any problem pane splitting. It is a lot easier than Emacs, that's for sure. I never looked back ever since. It is a world of a difference. I still use Vim (I currently do for editing C++, CORBA IDLs and shell scripting and sometimes for simple HTML/JSP and configuration files editing), but for Java development (in particular JEE development), Eclipse. I could use NetBeans as well, but I'm simply more accustomed to Eclipse.
I can't comment about Android development, but in general, yeah, you can do JEE development with Vim, but why would you? What exactly would one try to prove with that? There is a point to be made that people might have a tendency to grow too dependent on the IDE, unable to understand the nitty gritty, but that's just hand-waving. I doubt that such a person would also be a better programmer using a more "raw", primal development environment. And a good programmer will pick the right tool for the right job and would make it sing the tune he wants to.
Equally, I would be baffled to find someone that is a good developer that cannot get past the seemingly complexities of an IDE to get
Sadly, I'm afraid the average/. poster (or recently graduate CS'tist for that matter) wouldn't even understand the code refactoring you just proposed. Everything here is "blah, it's easy, I'm awesome, let me show you how", and then they drop a naive turd as an example.
Slashdot Mirror
They also made the surround on the Tab darker to make it look more like the iPad. Submitting photoshoped images to the court should cost them their case.
Not to mention that the "evidence" shows the Galaxy Tab in a vertical position when the default/intended usage is in a horizontal position.
Exhibit A: Samsungs Galaxy Tab 1.0 microsite: http://www.samsung.com/global/microsite/galaxytab/10.1/index.html
Exhibit B: Endgadget Galaxy Tab 1.0 review : http://www.engadget.com/2011/06/08/samsung-galaxy-tab-10-1-review/
Exhibit C: CNet's review : http://reviews.cnet.com/tablets/samsung-galaxy-tab-10/4505-3126_7-34505347.html
Call me conspiracy theorist, but this cannot be by accident. Morphed dimensions by itself an accident? Maybe (and that's pushing it). Shown in a vertical position as opposed to the horizontal position it is shown everywhere else as an accident? Maybe. But both, as legal evidence? Got to have been done on purpose.
A less than 7% change in the aspect ratio is negligible. And they're complaining about the size of a picture too? Good grief. The point is how similar the products look to consumers. Of course it's best to have things displayed at the same size to best see similarities in the design, any border width, curvature of corners etc.
If someone wants to fuss about small differences in size, please do something about those containers of ice cream that aren't a half-gallon any more. That's a crime against humanity!
Just because it is negligible to you that does not imply it is negligible to the case (after all, Apple claimed that they are "practically identical".) Considering the difference in aspect ratio, and the fact that the wrong evidence shows the Galaxy Tab in a vertical position (as opposed to the horizontal which is the default), then you see that there is a problem with the evidence presented to the judge as proof that these two products are "practically identical".
Whether you think that's a fuzz about nothing, that's as irrelevant as unquantifiable personal opinions go in a court of law.
Naturally a city with such a good infrastructure would also have plentiful fire hydrants.
Since that's the only fire rescuing infrastructure one would require in a city of significant size. Not to mention all the other infrastructure requirements for such type of population centers.
Slashdot posters can't seem to imagine anything but the suburban wastelands they live in.
Just because you imagine it does not translates it to the realm of the practical (or even efficient). There are a lot of ways to design civil infrastructure that is more eco-friendly, economical and sustainable. Yours ain't one of them. You haven't even put any thought behind them as you are simply defending the indefensible just as a matter of course. It is crap like this that gives sustainable engineering a bad rep among the common cattle. Despite what you might believe about yourself and your ideas, you are also part of the same mindless cattle (but just so happen to be munching grass on the other side of the corral.)
Also, a tendency to making derogatory assumptions (and that are easily falsifiable) on the readers that disagree is usually an indication that a logically weak point is being defended. But don't let that dissuade your exercising of your freedom of speech when making dumb posts and all that. So feel free to build up your strawmen, so long as you don't complain about the splinters you get from f* with it.
A forklift can tow water pumps, tanks, and other equipment without any trouble.
Ever drove one? I have, for work, and for years (when I was working full-time while getting my BS degree in CS.) They are great for lifting things up and down, but you have to drive them in reverse for safety (unless you drive the small types), they are designed for carrying things on their forks, not for hauling (very important distinction, just look at their wheels for Christ's sake), and I believe (I could be wrong in this) they are not designed for efficient traveling over the same distances you would expect a firefighter truck to do (not to mention they cannot sustain the same type of speed a truck would.) Granted, my experience with forklifts and similar equipment has been limited to their typical usage in warehouses (lifting heavy shit and move it from a warehouse/container to/from a transport/another container.) But based on my work experience alone, I do not believe what you are proposing is viable.
Forklifts or other small vehicles, of course.
Awesome idea for the local firefighter's department /facepalm+sarcasm.
Tear up half the road and use it for rail and the remaining half for bikes and pedestrians. Also, allow freight via light rail to eliminate the need for delivery trucks in the city.
How do emergency services operate?
They don't. People are self-reliant, are one with nature and all that kumaya shit.
wow. half-again and you're in orbit.
where do you need to go that fast?
"When the bomb absolutely has to be anywhere in the world in 30 minutes or less, DARPA is there!"
Where do you need to go that fast? Why do you need microwaves? Why do you need a protocol that allows people to send data over an unreliable network? Why do we need all of this?
I haven't read it either, but I think it should probably be overturned unless there's evidence for the extortion charge other than just doing a lot of it at once.
Extortion is about threatening harm to someone to get something you aren't owed. That's certainly a reasonable charge if I threaten to sue someone who doesn't owe me anything and I offer to take a small sum of cash rather than put them through the cost of a trial.
But if I own a patent and I see others selling products containing that idea, I'm owed royalties. The fact that there are a lot of infringers and I'm willing to settle immediately instead of demanding more and insisting on going to court to get it means I'm the good guy in the situation.
It's all about whether my case had merit. Maybe this guy's case didn't, for most of his targets.
But that is what's in the court's findings according to TFA. The lawsuit was without merit, and the plaintiff was not found to have broken any copyright laws. Ergo he owns nothing to the patent troll. Ergo, patent troll was trying to get something that he didn't own off the plaintiff. Furthermore, the court found that this was ample evidence that this was the patent troll's modus operandi. Ergo, patent troll has attempted to seize something he didn't own from other plaintiffs using similar, merit-less lawsuits.
Patent troll might have owned the patent, but the plaintiff didn't break it, and since the patent troll not only did not due due diligence as found by the court, the court itself found that patent troll has not done any due diligence at all when filing the hundreds of similar lawsuits. It is hard to argue, logically and legally, that this is not a systematic attempt at extortion not just against this specific plaintiff, but against many others (independently of whether patent troll owns the patents or not.)
While I don't disagree that spending must be cut, the problem with the majority of people and politicians who talk about spending cuts never seem to include military spending. Funny, that.
What are you talking about? There have been cuts on the military to the left and right.
Color me surprised that the Government sides in its own favor in its own cases.
I'd actually go out of a limb and suggest that maybe this below is a the root of the decision, not a by-default mechanism to judge to the government's favor (feel free to argue that this is not the case):
The main purpose of the Rojadirecta websites, however, is to catalog links to the copyrighted athletic events — any argument to the contrary is clearly disingenuous.'
Also, there have been numerous occasions where the supreme court has ruled against the government. But don't let these details bother you (after all, YOU know that is is true, and yet you wish to ignore it in order to make such a silly statement.)
The Java VM is a very poor abstraction for most underlying hardware. I think a general purpose IM would be a much better idea.
You know that the Java VM is not an abstraction for most underlying hardware, don't you. As I mentioned in my prev. post, it is an operating environment for a specific class of problems which provides a slew of app-specific services that are not necessarily general purpose. IM servers one type of purposes, VMs serve others.
Also, I know that you think like that. However, I *think* you need to qualify your stated opinion. Without it, it is as valuable as saying "I think oranges are better than apples."
I mean seriously, what do you mean by this?
The Java VM is a very poor abstraction for most underlying hardware.
Why? How? Under what conditions? More importantly, is that the JVM's objective? (hint: it isn't)
And and what to you mean by this?
I think a general purpose IM would be a much better idea.
Why? How? Under what circumstances? And if IM is a better alternative, how is it to implement the configurable gc logic, the class loading logic, the JMX and other management extension logic, the security manager logic, the reflection logic, the JNDI logic, the JDBC logic, all the specs that come with it (all of which are defined as universal standards for that application stack)?
Obviously it would have to be deployed in the OS as a shared library, and then you'll have to ask you why is that a better deployment/distribution model over the JVM, how and under what conditions.
Without that, all you are saying is that *you like* apples more than oranges. Not much helpful, isn't?
I've never understood why a virtual machine is, in any way, better than an intermediate language that can be compiled to native code for a particular platform.
For the same reason that in many platforms (x86 for instance), your compiled code gets compiled to high level instructions and not directly into microcode. In the same way that the x86 instruction set insulates you from possible chip architectural changes (that could change the underlying microcode), so does software-level vm instruction sets. The later provides you with a higher level of abstraction to work on, tends to simplify things, and provides a good-enough degree (but a 100% one) on portability across machine architectures.
An interpreted language may make sense for dynamically created code.
Java is not an interpreted language. It compiles to JVM byte code with very small resemblance to the original source code. An interpreted language is one that is parsed and, if valid, executed at run time. The adjective 'interpreted' doesn't fit here.
Even so, why not just compile it first?
But you do. You compile it into JVM bytecode. Compilation does not mean absolutely translate into hardware-specific machine instructions.
You can run interpreted code in a sandbox
Or you could run compiled code in a sandbox (pls see previous comment about interpreted vs compiled.)
but any IM compiler could add the same features to native code.
Yes, but then you have to implement back-end native instruction generators for the platforms. OTH, if you provide a VM (not just necessarily a JVM), which itself is compiled to a selected number architectures, and which code and behavior is narrower than the general cases one has to consider otherwise, then you only focus on the issues pertaining to application-specific code compiling to into that VM.
Also, a VM provides higher-level abstractions that make development of apps (and compiler toolchains and introspection tools) easier.
One thing to remember is that a VM (and the JVM in particular) provides another layer of abstraction with services and constrains not necessarily available (nor desirable) at the OS level.
For better or worse, depending on how you want to look at it, the JVM provides a security model, a memory model, a concurrency model, etc. It provides class loading and reloading capabilities, integrity checking of classes before loading, easier mechanisms for bytecode manipulation and reflection (this extremely important for most app-level development), a robust JIT, configurable garbage collection algorithms that you can configure according to the type of hardware you have, and so on and so on.
So the JVM is not just a bytecode interpreter, but an entire operating environment with high-level services targeted for a specific class of problems (and the applications that solves them.) For that type of application development, a VM makes more sense than direct compilation to an architecture instruction set on an executable format that is typically OS-specific.
I thought that on x86 at least, most Java is JIT compiled to high performance native.
Just-in-time compilation
HotSpot
In all major platforms the JVM runs, not just on x86. Heck, there are high performance platforms out there (Azul comes to mind) that have the JVM, the JIT, the GC and a lot of other things running on the dye.
Methane, Large sources of easily available water, or Oil. One of those three are the most likely.
Considering the focus on geology, it's also possible they've found a surface deposit of some rare earths minerals (such as those which are currently exported only by China), though you're right, methane is probably the most likely, and while geologists studying Mars might find it interesting, it's not nearly as significant to the rest of the human race.
Focus on geology? What else would you expect study of a planet to be focused on? That's what geology is.
Oil? Obviously you must be joking.
Oh, and rare earths aren't; rare earth ores are somewhat more so, but that is more a function of economics than anything else (an ore is an economically recoverable mineral resource; there are ample rare earth mineral resources around Earth, just not generally economic to recover - but that depends entirely on the price). No amount of rare earths on Mars are going to mean anything to anybody in economic terms until long after people are living there, if ever.
That would move people off their asses off to the nearest start, certainly to Mars as well.
Java kinda sucks as a language.
Google should designe a better high level language around the LLVM stack while improving the LLVM stack itself.
http://en.wikipedia.org/wiki/Is-ought_problem
Your fact #1 is not a fact, merely a bunch of chicken littles misinterpreting a MS demo.
It is a demo of what? Flipping burgers? No. It is a demo of a possible dev stack. Ergo, I used the word "seems" rather than "will".
The recent unsettling behavior at Microsoft concerning .NET makes it a good time to re-evaluate what the technology is all about. It may have been good technology but with the systems guys building Windows preferring to stick with C++ the outcome was inevitable. Because they failed to support its way of doing things .NET has always been a second class Windows citizen unable to make direct use of the Windows APIs — especially the latest. .NET started out as Microsoft's best challenge to Java but now you have to ask what has the excursion into managed code brought the Microsoft programmer and indeed what good has it done Microsoft? From where we are now it begins to look very much like an unnecessary forced detour and Windows programmers are going to be living with the mess for years to come.
There are two, possibly unrelated factors to take into account here: 1) appropriate support for .NET, and 2) the value of managed code.
I would argue that the last thing one wants to do, in general, is to NOT use managed code for application development, in particular application code that is subject to continuous modifications and deployments.
That Windows systems developers prefer to stick to C++ (and actually C as you go deeper), that should not come as a surprise. I would be a surprise if anyone half-literate in software development would think otherwise. I would be more surprised if anyone would expect anyone but a dumb-wit to do low-level systems development with managed code.
So, I don't understand why an understandable preference to do systems development with a systems language (which just so happens to be C or C++, but which could have been Ada or Pascal) would have a detrimental impact on using a managed code platform and stack for the general case of application-level development.
Me no get it. Does not compute.
Moreover, it seems that the author of this piece is conflating issues here. This is what the author seems to be going about:
1. Fact: MS seems to be moving towards JavaScript and HTML5 as the main development stack for application development instead of .NET
2. Fact: System-level Windows programmers use a systems level programming language (C++) for systems-level development.
-----------
Ergo: Oh shit, the later caused the former!(10+1)
Correlation does not mean causation. And in fact, there isn't even a correlation at all. Whether MS drops .NET in favor of HTM5 and JavaScript does not mean anything about MS venturing into managed code land. And I would be hard-pressed to imagine that MS does not have any plans for the significant investment it has made in the .NET platform.
The funniest thing of all is that the author seems to miss this important fact: JavaScript is managed code. So in essence, MS is simply moving from one managed code stack "a" to another managed code stack "b". That's all. Fundamentally, it is just that, a change of managed stacks, a reflection (or adjustment) to the changes, to the paradigm shifts in application delivery. Nothing more.
How a preference for C++ for Windows systems level programming is even in the picture here, it beats the hell out of me.
How is a half-black, half-Latino teenager more politically correct than a white teenager?
I completely agree with this. The change to some sort of racial token guy was a stupid publicity stun. Not to mention that 'half-black, half-Latino' is an oxymoron as there are black Latinos.
What's important in comics (or it should be) is the story and the super hero original character, not a ethnic makeup change. People don't give a rat's ass if he's a dreadlocks-wearing transgender half-mix between Flores Island Hobbits and Druids, raised and fed by Chinese-raised Klingons immigrants the futuristic ghetto of District 9 (although sadly, this is going to be the recipe for the next Twilight Spiderman Xtreme Ultimate, DragonBall-Z-meets-Sailor-Moon edition.)
If you are completely crippled by your tools not being available, you are not "intelligently using tools available."
This is an absolutely true statement... when you take it all by itself, just like saying "the sky is typically blue in the desert". Great, good for you. You are still re-iterating the extreme, negative case on a false dichotomy. You don't prove that a dichotomy exists by reiterating one side of it. You do so by showing that there is nothing in between the extremes. It is not an inevitability to become completely crippled by the tools at your disposal just because of their prevalence.
Many developers are baffled by things like memory management or reference counting, and want the language to figure out when memory is no longer in use
Non-sequitor. What you are describing is a function on the exposure of low-level programming languages, not on the availability of integrated environment tools. I've programmed in C, C++ and Assembly (plus Ada and Pascal where you can still get your SEGFAULTS), and now I'm going to lose proficiency in low-level management crap just because all of the sudden I use Eclipse with a C/C++ plug-in and Valgrind and VectorCast and all other high-level tools? I start working with an integrated development environment for Java enterprise development, and I'm now going to be baffled at the sight of memory management?
There are individuals out there doing app-level development who have not have had any exposure to these kind of things, but to suggest or even believe that such is the general case is such a display in self-congratulatory wishful thinking, it is just ridiculous. Don't delude yourself into thinking that people who do C or C++ fare any better. I've seen code on both sides of the equation. Not pretty.
and garbage collect it because they simply can't wrap their head around the idea of tracking data;
And that shows me you have no clue what you are talking about. You use garbage collection for application-level code, concentrating the tasks of memory book-keeping in a safe, tried-and-true, tested-till-it-bleeds critical section of your infrastructure, based on reliable, robust GC algorithms. Then you put your energy and efforts in developing the algorithms necessary for implementing the app-specific requirements, which, by the very nature, are highly volatile. Direct, manual memory book-keeping has absolutely no place in app-level code (in the same way that runtime type identification and reflection have no place, most of the time, in systems-level code.) Anyone who tries to do otherwise should be fired on the spot.
many others sit down and design a program before writing spaghetti code, and occasionally cause implementation bugs.
Which occurs also among programmers that do C and C++ with nothing but Vim and gcc (and I have the code to prove it.) So what's your point?
While you can be competent and write in Java, you can also turn white at the mention of C (and immediately confuse it with C++)
Well, I don't, and a large number, if not the majority of Java developers with a solid CS degree do not either. Even for a CS graduate who hasn't had work experience in systems level programming and goes straight into application level programming using Java or what not, what on earth do you think CS students do when they do their OS and Unix programming courses?
It is a pervasive fallacy - held by some, God only knows why - based on a morbid exaggeration of an actual problem that manifests itself in many forms across applications and systems programming domains.
and use Java to simulate knowing what in the hell you're doing.
You love the sound of that, don't you?
Fair enough, I haven't used it long enough to even be bothered to personalize that. My main question would be WHY are tabs not characters? Why should having to hit backspace 4 times to knock down indentation one level be a default?
Because your default way of doing is highlight/shift+tab? Not counting the fact that auto-indentation in Eclipse is 1) highly configurable (you can tell it to auto-format brackets, spaces and what-not with just a few clicks); 2) it is automatic; and 3) it is very efficient. It ain't rocket science. Well, it might have looked like that back in the day when we had nothing but vim (or ed or some archaic crap like that) over a VT-100 terminal with they keyboard mappings all fucked up. But now, in 2011? I mean, c'mon.
What benefit is there?
Allowing spaces instead of tabs makes sure that the intended visual impact of indentation remains the same (most of the time, but not always), independently of whether you open the source code in VIM, Notepad++, pico/nano, Notepad, Eclipse, NetBeans, JDeveloper. Edge case mind you: sometimes you still have a 120-column dot-matrix printer (which is the best thing for printing reams of code), you cat the code down to that bad boy, and you want the indentation to appear in the printer exactly how they come up in the screen. Typically, you cannot do that if you use tabs.
Unless you are doing JavaScript - where you sometimes have to be mindful of the actual number of bytes being send down the wire - this is a non-issue. And even with JavaScript, one can always maintain the source code indented in any specific way, with the .js files being passed through a "compactor" before being deployed or sent to the client's browser.
It is really a non-issue. No, really, seriously. At most, it is a mild annoyance of no significant consequence.
would love to have worked with this guy during the 2009 uprising. He has a point, those twitter revolutionaries will behave "better" ("better" as defined by the old guard) would they have used their real names.
Yeah, I was too vague when I said that. The integration in Eclipse is well done. Eclipse itself (editing) is awful. Things like Eclipse automatically adding random lines (like imports) whenever I copy and paste between files? Yeah, that's a terrible feature. Panes/splitting and pane management is very obscure as well. Oh, and tabs are characters, not 4 spaces - seriously fucking stop with the tab conversion.
C'mon man, this is 2011.
1. Window/Preferences/Editors/Text Editors/Insert spaces for tab (uncheck)
2. Windows/Preferences/Java/Code Style/Formatter/Active Profiler/Edit/Indentation Tab/Tab Policy: Use spaces to indent wrapped lines (uncheck)
You find those two in a most trivial manner. JFGI Eclipse style. Simply enter "tab" in the search box in the Windows/Preference window, and voila, it shows you how to control tab expansion. This is a capability present in any modern IDE or code editor. It is something trivial that one should reasonably expect any developer to figure it out rather quickly.
There are a lot of challenging things in software. This ain't one of them.
Some of us juggle all that stuff in our heads and have a complete map of our code, which becomes difficult to track when we have to deal with automagic shit or go make amendments or deletions from one side or the other.
There is no automagic. There never is. There are IDE-assisted automatic features (the majority of which is useful), the configuration and behavior of which are not rocket science, and which we either understand or we do not.
Others write bits of business logic and string it together, and hope it works; often these people rely on development environments to take care of some of the stringing together.
False dichotomy between the previous case and the later ones. It might surprise to some, there is people out there who understand the code and intelligently use automated tools for integrating it. We don't get paid to show off our l33t hax0r skills, but to intelligently use tools available for coding to our employer's benefit.
I will also argue, and there is plenty of evidence of it, that, unless you are an absolute genius, if you can completely map the code out in your brain, the complexity (not necessarily the size) of that code is trivial, or small-sized at best. Some languages (say Ruby or Python) are better than others (Java, C++) for helping the developer write more succinct, mentally-manageable code. But beyond a certain size and complexity, independently of whether it is systems or application development, one simply cannot claim to mentally map the code (unless you are the owner of a module and you are actively maintaining it.)
Also, it is a false dichotomy to present business logic and code as separate entities. Business logic gets implemented on code, on top of other non-functional requirements. Code is the executable representation of business logic, it is knowledge captured and codified in software. Break that relationship, and all you have is code for shit. Business logic changes constantly causing inevitable code/system changes and increasing entropy (yes, the 2nd law of thermodynamics applies to software).
It is our job to put constant effort in controlling/negating entropy in the affected systems. And that's what integrated environments are for, to provide for automated tools that when used intelligently in conjunction with good programming practices helps with that part of the software development cycle. These are just tools and they perform according to the hand that wields them. This is something that is sadly neglected or considered irrelevant or trivial.
Yeah, I was too vague when I said that. The integration in Eclipse is well done. Eclipse itself (editing) is awful. Things like Eclipse automatically adding random lines (like imports) whenever I copy and paste between files?
If by "random" you mean the actual imports needed for the things you copy and paste...
Yeah, that's a terrible feature.
No, it is a problem between the keyboard and the chair.
Panes/splitting and pane management is very obscure as well.
Exactly how? It ain't rocket science. I'm really honest about this.
Oh, and tabs are characters, not 4 spaces - seriously fucking stop with the tab conversion.
Wow, just absolutely wow.
Dude, just do the following:
-- Window/Preferences/General/Editors/Text Editors/(Uncheck)Insert spaces for tabs
-- Java/Code Style/Formatter/Edit Active Profile/Indentation/Tab Policy - Use spaces to indent wrapped lines.
Or simply go to Window/Preferences and type "tab" in the search, and it will show you what settings to change. I can understand a non-technical person not finding a way to change the editor's behavior, but a developer? C'mon. This is like a Winloser saying that gcc on Unix doesn't work because he/she doesn't find a resulting .exe file.
Also, when it comes to tabs over spaces, why would you be so anal about it? It's a freaking config setup, and sometimes, if you work with a team with a retarded set coding standards, they mandate what to use (ergo, not up to you.) And sometimes you inherit code that doesn't necessarily align to your formatting predilections. What do you do then? Do you reformat it all out of the blue? No, you work through. In general, it's a non-issue.
I personally prefer spaces over tabs anyways because I know that the original indentation (which is very important to me) will remain the same independently of whether I open the source code with Eclipse or Vim or Notepad. But that's just me.
For record I used vim for the longest time (funnily I switched from Emacs to Vim), then briefly used JEdit and JDeveloper, picking up Eclipse just recently (back in 2007). I've never had any problem pane splitting. It is a lot easier than Emacs, that's for sure. I never looked back ever since. It is a world of a difference. I still use Vim (I currently do for editing C++, CORBA IDLs and shell scripting and sometimes for simple HTML/JSP and configuration files editing), but for Java development (in particular JEE development), Eclipse. I could use NetBeans as well, but I'm simply more accustomed to Eclipse.
I can't comment about Android development, but in general, yeah, you can do JEE development with Vim, but why would you? What exactly would one try to prove with that? There is a point to be made that people might have a tendency to grow too dependent on the IDE, unable to understand the nitty gritty, but that's just hand-waving. I doubt that such a person would also be a better programmer using a more "raw", primal development environment. And a good programmer will pick the right tool for the right job and would make it sing the tune he wants to.
Equally, I would be baffled to find someone that is a good developer that cannot get past the seemingly complexities of an IDE to get
Remember that every cycle counts. Depending on the architecture and compiler, you might want to refactor that code as:
Sadly, I'm afraid the average /. poster (or recently graduate CS'tist for that matter) wouldn't even understand the code refactoring you just proposed. Everything here is "blah, it's easy, I'm awesome, let me show you how", and then they drop a naive turd as an example.