Mistrial? Well, we'll see... I think the judge should just overrule the Jury as a matter of law. "It's not covered by copyright and therefore not infringement."
Well, yes. Google will only want a mistrial if the judge decides the opposite. Fortunately, they should be able to get it: the jury has failed to agree on whether or not the use is fair use, which seems like a pretty fatal flaw in the verdict *if* they copyright is valid.
I've been running web sites on shared hosting at a wide variety of hosts since circa 1997, and never once have I had a per-hour limit on my number of database queries. If you have, you need to change your host.
Right now, stripboard remains the choice for hobbyists
Yes, but not for long. More and more projects, at least in my experience, are requiring components that aren't available with 2.54mm pin spacing, leaving stripboard a rather antiquated system that will soon be almost useless except for beginners' projects.
You can actually find bible verses that 1 state that the earth is ROUND 2 is in orbit and if you look at things in context are actually scientifically sound
Go on then, show them to me. I think you will find they are being misinterpreted.
the real trick is the first 20 picoseconds of TIME can not be approached using Science but must be approached using Logic And Faith.
Science can't explain that very early period. Yet.
The difference is that there is no chance that logic or faith will ever achieve this.
I've always called it the "number sign", but most voice mail systems refer to it as the "pound key" for some reason.
Except in the UK, where they tend to refer to it as "square". Which is perhaps even more bizarre.
# was used as an abbreviation of "pound" because, I believe, it is considered to vaguely resemble the letters "lb", which are a common abbreviation of "libra", which is Latin for "pounds".
It's called a pound symbol because ASCII (And the character sets that once competed) didn't have a £ symbol. They were designed in the US, and with only seven bits to work with there was no room for symbols with little use in that country like accented characters and non-dollar currencies. So until the coming of unicode and other means of character encoding, typing a £ in the UK tended to break things - the only way to represent it was the upper-ascii character that not all software supported.
You seem to have it the wrong way round. The placement of £ at ASCII 35 in some early UK computer systems is, I am led to believe, based on a misreading of the ASCII standard based on the fact that it used the then already common (in the US) term "pound sign" to refer to the hash.
People used a # symbol in place of the £ and shouted curses about stupid selfish yanks.
No, we actually had computers that couldn't manage to produce a # symbol, and printed £ instead. To this day, if you have an Epson-compatible printer (which many of the printers used in POS systems, for example, still are), you can send it ^[R3 to cause it to make this substitution.
To this day, when I am using MUCKs, I cannot send a £ symbol. The software, written long before unicode, simply drops the character as invalid.
You're lucky it's even that smart. I've worked with systems that will drop the *connection* if they encounter a character > 128.
So that web page developers can push hot fixes to production deployments...
Reminds me of this story... A client called me a couple of months ago, asking me to look at a site he'd had built by someone else. He was getting warnings from Chrome about malware on the site. Turns out there was a PHP script left in the root folder that allowed anyone with the right password to execute any shell script they wanted... somebody in croatia had been using it to inject javascript malware droppers into his site. The irony was, it was an entirely static site: PHP should have been disabled to prevent this kind of thing happening.
1. This is what/tmp is for./tmp has 777 file permissions, so the requirement for setuid script execution doesn't apply to accessing it, therefore it doesn't have the problem the GP post was complaining about.
2. I wouldn't usually call thumbnails "junk data". They're actual data associated with your records, so they should be treated as such (IMO).
3. You'd get much better performance from using something like memcached rather than filesystem-based cacheing, anyway.
To me, this just sounds like a reason to avoid using these systems. I don't trust their developers not to have screwed up the file manipulation, something that I know from experience to be extremely hard to get right in this context. Time after time you see web applications and frameworks whose security is undermined by a basic assumption about file handling that isn't true.
So that your assets aren't stored as DB blobs, the slowest and worst possible way in which to store files?
The notion that blobs are slower than files is a myth. Benchmarks show that database access is actually faster in most situations than file access (at least with MSSQL and Windows Server using NTFS).
The problem with automated wire wrapping is the cost of the equipment - about $20,000. The equipment needed for the method described in TFA costs about a tenth that.
Newsflash: PCBs have been around for decades and they are now approahcing the same density and complexity as early ICs. You think you'll be getting anywhere near that in your living room? Um, no?
No, but the equipment to produce them costs somewhat more than the $2,000 a 3d printer will set you back, and will take up a lot more space than most people have available. Alternatively, hiring other people who already have the equipment will set you back $50 or so per board for small quantity orders.
The fact that this could possibly be done with reasonably cheap equipment that a hobbyist can feasibly afford *is* a breakthrough. Yes, it's irrelevant to the professionals who will continue to do things in the better way that requires more expensive equipment, but for the rest of us, this kind of thing is important.
(OTOH, the stuff linked in the article isn't exactly there yet...)
Why on Earth would you want a web-facing page to be able to manipulate files? Correct file handling in a web context is notoriously difficult, and is often a source of security problems (particularly if the files are uploaded). The best thing to do would be to store any data you want to use on a database; then it doesn't matter what UID your scripts run under.
Moron. What's interesting is that this is a full JIT JVM, not just a bytecode engine like Dalvik.
Dalvik has been doing JIT since Android 2.2 was released nearly 2 years ago. Please try to keep your facts up-to-date if you're going to claim other people are spreading FUD.
WTF is wrong with you Google!? JAVA IS AN AWFUL LANGAUGE! Why the hell didn't you just use C++?
Because in order to support the fine-grained permissions system Android has, they needed a language that supports full type safety, i.e. that disallows casting a pointer to an object to a pointer to a different kind of object. C++ can't do that, and while Objective C is closer it's still a "no cigar" situation. It's impossible in C++ to write a library that reliably acts differently depending on whether its client is trusted or not, and while I think it's theoretically possible in Objective C the fact that you can create new implementations of basic types (e.g. strings) allows all kinds of attacks that are simply not possible in a less dynamic language like Java where this can be prevented.
That's exactly it. If even one of the most prominent Java users Google is sued only for using the Java API (as basis for their own VM), then just imagine if someone else uses the API in combination with Oracle's own JVM, they'd have even less defense. And most people probably are not even able to pay for a Google-style lawyer army.
Except that Oracle has explicitly publicly licensed that API for use with their implementation (and any other implementation that passes the tests in a test suite that they'll offer to sell you).
But as the API is distributed under GPL-with-classpath-exception (which essentially says "you can use this to link an application with however you want, but if you distribute it as a library it has to remain under GPL") it doesn't matter to a typical user whether the API is copyrighted or not: there is a publicly available licence that allows you to use it under almost any terms you might want.
This is the nice thing about free software -- its copyright holders can try as much as they want to screw you over, but in the end they have agreements in place that prevent them from doing so.
Except drives don't use 10W. Looking at one I pulled from a machine recently to put a bigger one in, it's rated maximum consumption is 8W, but in actual use (1) it'll only use that much occasionally -- while it's both spinning its platters up from stationary and seeking at the same time -- and (2) in an application like this it'll likely be in a power saving mode 75% or more of the time. I'd hazard about 1.5W is a much more reasonable figure to use as an estimated average.
Using a laser transmitter would require the receiver to stand in exactly the right place, only one receiver could use the system at a time, and transfers would be interrupted by accidental movements. It would be too hard to use for anyone to actually want to use it.
Either 802.11g/n or bluetooth could be used for the purposes you describe and would be much more convenient for everyone involved.
I'm pretty sure that if you got the price down to about $50, people would find a lot more uses for this, including sharing network connections with friends (in particular in rural areas), secure communications, and distributing access points. Not everybody lives in cities with otherwise excellent coverage.
I don't think it'd be useful for those applications. Reading TFA, this device has a useful range of approximately 10m, which is somewhat limiting. Even without this limit, houses in rural areas are unlikely to have undisturbed line of site. Birds will be a problem (current commercial systems solve this by using redundancy to allow routing around birds, I believe, which makes your $50 an unrealistic target price). To make these things work properly, they really need to be on top of tall buildings to ensure nothing comes between them. Security would be difficult to guarantee because (at least theoretically) you can intercept data that's refracted out of atmospheric moisture. Sure, you'd need a very sensitive receiver, but such things are possible. Again the line-of-sight thing is going to be a problem for distributed access points. And in the end, even if they are $50, you can achieve the same thing with a $20 802.11n access point and a $20 unidrectional antenna.
Not really, the 9 lines in question were not a direct port of any of the code in the python implementation, but rather a simple range check to ensure that accesing a range of items in an array was a valid action prior to starting the sort. As the python operation worked on lists or list slices (which come with embedded pre-checked range data) rather than array ranges, it did not need to perform this action.
Slashdot Mirror
Mistrial? Well, we'll see... I think the judge should just overrule the Jury as a matter of law. "It's not covered by copyright and therefore not infringement."
Well, yes. Google will only want a mistrial if the judge decides the opposite. Fortunately, they should be able to get it: the jury has failed to agree on whether or not the use is fair use, which seems like a pretty fatal flaw in the verdict *if* they copyright is valid.
I've been running web sites on shared hosting at a wide variety of hosts since circa 1997, and never once have I had a per-hour limit on my number of database queries. If you have, you need to change your host.
Right now, stripboard remains the choice for hobbyists
Yes, but not for long. More and more projects, at least in my experience, are requiring components that aren't available with 2.54mm pin spacing, leaving stripboard a rather antiquated system that will soon be almost useless except for beginners' projects.
You can actually find bible verses that 1 state that the earth is ROUND 2 is in orbit and if you look at things in context are actually scientifically sound
Go on then, show them to me. I think you will find they are being misinterpreted.
the real trick is the first 20 picoseconds of TIME can not be approached using Science but must be approached using Logic And Faith.
Science can't explain that very early period. Yet.
The difference is that there is no chance that logic or faith will ever achieve this.
Not a twitter user either, but from what I've seen # identifies a topic keywork, @ identifies another user.
Twitter just stole the character from IRC, anyway. I suggest everyone who used the Internet before about 1996 gets together and demands it back.
I've always called it the "number sign", but most voice mail systems refer to it as the "pound key" for some reason.
Except in the UK, where they tend to refer to it as "square". Which is perhaps even more bizarre.
# was used as an abbreviation of "pound" because, I believe, it is considered to vaguely resemble the letters "lb", which are a common abbreviation of "libra", which is Latin for "pounds".
It's called a pound symbol because ASCII (And the character sets that once competed) didn't have a £ symbol. They were designed in the US, and with only seven bits to work with there was no room for symbols with little use in that country like accented characters and non-dollar currencies. So until the coming of unicode and other means of character encoding, typing a £ in the UK tended to break things - the only way to represent it was the upper-ascii character that not all software supported.
You seem to have it the wrong way round. The placement of £ at ASCII 35 in some early UK computer systems is, I am led to believe, based on a misreading of the ASCII standard based on the fact that it used the then already common (in the US) term "pound sign" to refer to the hash.
People used a # symbol in place of the £ and shouted curses about stupid selfish yanks.
No, we actually had computers that couldn't manage to produce a # symbol, and printed £ instead. To this day, if you have an Epson-compatible printer (which many of the printers used in POS systems, for example, still are), you can send it ^[R3 to cause it to make this substitution.
To this day, when I am using MUCKs, I cannot send a £ symbol. The software, written long before unicode, simply drops the character as invalid.
You're lucky it's even that smart. I've worked with systems that will drop the *connection* if they encounter a character > 128.
So that web page developers can push hot fixes to production deployments...
Reminds me of this story... A client called me a couple of months ago, asking me to look at a site he'd had built by someone else. He was getting warnings from Chrome about malware on the site. Turns out there was a PHP script left in the root folder that allowed anyone with the right password to execute any shell script they wanted... somebody in croatia had been using it to inject javascript malware droppers into his site. The irony was, it was an entirely static site: PHP should have been disabled to prevent this kind of thing happening.
1. This is what /tmp is for. /tmp has 777 file permissions, so the requirement for setuid script execution doesn't apply to accessing it, therefore it doesn't have the problem the GP post was complaining about.
2. I wouldn't usually call thumbnails "junk data". They're actual data associated with your records, so they should be treated as such (IMO).
3. You'd get much better performance from using something like memcached rather than filesystem-based cacheing, anyway.
To me, this just sounds like a reason to avoid using these systems. I don't trust their developers not to have screwed up the file manipulation, something that I know from experience to be extremely hard to get right in this context. Time after time you see web applications and frameworks whose security is undermined by a basic assumption about file handling that isn't true.
So that your assets aren't stored as DB blobs, the slowest and worst possible way in which to store files?
The notion that blobs are slower than files is a myth. Benchmarks show that database access is actually faster in most situations than file access (at least with MSSQL and Windows Server using NTFS).
The problem with automated wire wrapping is the cost of the equipment - about $20,000. The equipment needed for the method described in TFA costs about a tenth that.
Newsflash: PCBs have been around for decades and they are now approahcing the same density and complexity as early ICs. You think you'll be getting anywhere near that in your living room? Um, no?
No, but the equipment to produce them costs somewhat more than the $2,000 a 3d printer will set you back, and will take up a lot more space than most people have available. Alternatively, hiring other people who already have the equipment will set you back $50 or so per board for small quantity orders.
The fact that this could possibly be done with reasonably cheap equipment that a hobbyist can feasibly afford *is* a breakthrough. Yes, it's irrelevant to the professionals who will continue to do things in the better way that requires more expensive equipment, but for the rest of us, this kind of thing is important.
(OTOH, the stuff linked in the article isn't exactly there yet...)
Why on Earth would you want a web-facing page to be able to manipulate files? Correct file handling in a web context is notoriously difficult, and is often a source of security problems (particularly if the files are uploaded). The best thing to do would be to store any data you want to use on a database; then it doesn't matter what UID your scripts run under.
Moron. What's interesting is that this is a full JIT JVM, not just a bytecode engine like Dalvik.
Dalvik has been doing JIT since Android 2.2 was released nearly 2 years ago. Please try to keep your facts up-to-date if you're going to claim other people are spreading FUD.
WTF is wrong with you Google!? JAVA IS AN AWFUL LANGAUGE! Why the hell didn't you just use C++?
Because in order to support the fine-grained permissions system Android has, they needed a language that supports full type safety, i.e. that disallows casting a pointer to an object to a pointer to a different kind of object. C++ can't do that, and while Objective C is closer it's still a "no cigar" situation. It's impossible in C++ to write a library that reliably acts differently depending on whether its client is trusted or not, and while I think it's theoretically possible in Objective C the fact that you can create new implementations of basic types (e.g. strings) allows all kinds of attacks that are simply not possible in a less dynamic language like Java where this can be prevented.
That's exactly it. If even one of the most prominent Java users Google is sued only for using the Java API (as basis for their own VM), then just imagine if someone else uses the API in combination with Oracle's own JVM, they'd have even less defense. And most people probably are not even able to pay for a Google-style lawyer army.
Except that Oracle has explicitly publicly licensed that API for use with their implementation (and any other implementation that passes the tests in a test suite that they'll offer to sell you).
But as the API is distributed under GPL-with-classpath-exception (which essentially says "you can use this to link an application with however you want, but if you distribute it as a library it has to remain under GPL") it doesn't matter to a typical user whether the API is copyrighted or not: there is a publicly available licence that allows you to use it under almost any terms you might want.
This is the nice thing about free software -- its copyright holders can try as much as they want to screw you over, but in the end they have agreements in place that prevent them from doing so.
Except drives don't use 10W. Looking at one I pulled from a machine recently to put a bigger one in, it's rated maximum consumption is 8W, but in actual use (1) it'll only use that much occasionally -- while it's both spinning its platters up from stationary and seeking at the same time -- and (2) in an application like this it'll likely be in a power saving mode 75% or more of the time. I'd hazard about 1.5W is a much more reasonable figure to use as an estimated average.
Who cares, as long you've configured enough spares?
Unless he means they've been modified to look like another drive so that they won't be spotted as stolen. (cf http://ringer.urbanup.com/3183368 )
denying customers access to my services because they are using an out of date or badly configured system makes no sense
Unless you are in a sector where you can be held responsible when your users' authentication is compromised, such as banking.
Yes, which probably account for 1% of all SSL enabled servers, so is statistically insignificant.
Using a laser transmitter would require the receiver to stand in exactly the right place, only one receiver could use the system at a time, and transfers would be interrupted by accidental movements. It would be too hard to use for anyone to actually want to use it.
Either 802.11g/n or bluetooth could be used for the purposes you describe and would be much more convenient for everyone involved.
I'm pretty sure that if you got the price down to about $50, people would find a lot more uses for this, including sharing network connections with friends (in particular in rural areas), secure communications, and distributing access points. Not everybody lives in cities with otherwise excellent coverage.
I don't think it'd be useful for those applications. Reading TFA, this device has a useful range of approximately 10m, which is somewhat limiting. Even without this limit, houses in rural areas are unlikely to have undisturbed line of site. Birds will be a problem (current commercial systems solve this by using redundancy to allow routing around birds, I believe, which makes your $50 an unrealistic target price). To make these things work properly, they really need to be on top of tall buildings to ensure nothing comes between them. Security would be difficult to guarantee because (at least theoretically) you can intercept data that's refracted out of atmospheric moisture. Sure, you'd need a very sensitive receiver, but such things are possible. Again the line-of-sight thing is going to be a problem for distributed access points. And in the end, even if they are $50, you can achieve the same thing with a $20 802.11n access point and a $20 unidrectional antenna.
Not really, the 9 lines in question were not a direct port of any of the code in the python implementation, but rather a simple range check to ensure that accesing a range of items in an array was a valid action prior to starting the sort. As the python operation worked on lists or list slices (which come with embedded pre-checked range data) rather than array ranges, it did not need to perform this action.