In fact, a judge has already thrown a case that did go to court out on the grounds that it was unclear why the damages were set at the level claimed or that they were in any way proportionate to actual damage.
The retailers (usually big supermarkets) are attempting to recover the entire costs of their losses to shoplifting and extra security from those they catch.
The business model of these companies is particularly pernicious, and relies in the main on the defendants being uninformed and under-resourced.
THe company in question here is actually chasing employees of the Citizens' Advice Bureau - the place where these defendants go for help - often because they can't afford a lawyer.
This is a similar strategy to that used by ACS:Law - which has already felt the wrath of the professional regulator for precisely this kind of tactic. It's quite likely that, as suggested, that they sent a few threats too far.
In fairness to London Underground, they have periodically looked at the possibility of providing mobile coverage in stations and trains, but none of the networks were interested in getting involved (and pay for it).
In the grand scheme of things, LU has more pressing needs for its funds.
Actually, it's not - large amounts of it are licensed from 3rd parties - as is the way with all ARM SoC devices - which Samsung then fabricates using its process.
I'd personally consider myself to be a Engineer rather than a programmer (to be precise, I'm a professionally qualified electronics engineer who engages in software and hardware engineering). Cutting the code is a small fraction of what I do, and I tend to do it a variety of programming languages on multiple platforms.
I'm really not in the business of having a dick-waving contest about how hardcore my tools are (an argument that is usually advanced in terms of their lack of features). Instead I expect them to help me along the way.
Modern, commercially developed IDEs genuinely improve my productivity, and I really notice their absence when working for platforms without them.
It's entirely necessary if using the compiler to drive code completion, syntax highlighting and in-edtior display of compiler errors and warnings. All of these are things are highly interactive and users will notice the lag of GCC getting invoked every time they type a character in their editor. GCC's clunky pre-compiled header support really doesn't help matters.
Of course, as I said earlier, lots of tools have provided this kind of functionality without deep integration of the compiler into the editor, but ultimately to do it properly, you'd still be looking at a great deal of effort to implement the first couple of stages of the compiler pipe-line and get an AST (or equivalent).
There is another excellent reason why the Linux Kernel is staying on GPLv2: a very large proportion of Linux's market share these days is on ARM SoC in mobile devices. There is truckloads of IP in these devices, and right now the chipset vendors are able to keep this closed and compartmentalised.
It's not a case of these chipset vendors wanting to keep their own IP private - often it's not theirs to start with, having been licensed - probably several times already - from other parties.
You can bet that a GPL3 kernel would cause an enormous fork - or even an industry-wide platform switch to something else.
There's also the awkward truth that the vast majority of Linux run-times sold are in mobile phones and other embedded devices and a very, very long way from being 100% open source software.
One of the key design objectives of Clang is that it is highly modular, and implemented in such a way that various compilation stages are self-contained, and have clean APIs and data structures. This allows development tools such as IDEs to link directly against the stages of the compilation pipeline then need to implement syntax highlighting, code completion, refactoring tools and so on.
Apple's XCode does precisely this, and licensing and lack of modularity in the GCC source tree would have been major factors in their choice to support Clang and LLVM development.
The traditional way of implementing these functions in IDEs has been to effectively re-implement the front-end of the compiler (often not completely). This is a big deal when developing in C++ against the STL/Boost/TR1 when you find that code completion can't grok template properly. This is something that XCode and Visual Studio (which takes a similar approach) are both capable of doing.
I'd imagine that under the zero-tolerance policing strategy in many US cities, people engaged in almost all of these activities would simply get arrested for petty criminal offences and cleared off the streets.
The point of anti-social behaviour orders is that they are executed under civil - rather than criminal - law. The idea being that a lower burden of proof is required in court to obtain the order in the first place. In practice, the evidence usually consists of a long record of low-level criminality - a possible example being an individual who is clearly dealing drugs, but who the police have never managed to catch with any.
Of course things on in the realm of the criminal law once the order is breached.
I found it distinctly unpleasant to work in too. It is said that one can acclimatise to it though. Be warned though - the evenings are not necessarily cooler than Western room-temperature.
The Japanese have been very successful in curbing demand. I was over in Japan for a week on a business trip last year, and it was interesting to see how they did it. This included absolutely all hand-driers in toilets being switched off, less air-conditioning (room temperature was set for 28C in the office), the business week of large corporations shifted to reduce peak-week-time demand and increase that on the weekend, and a move to more relaxed corporate dress-code - which included in many cases, a small towel attached to the waistband with which to mop off the sweat form the oppressive environment. There were no doubt more measures that I wasn't aware of, but life definitely carries on as normal without power cuts.
Our suspicion is that this state of affairs will become the norm.
I think the point here is that whilst applications do indeed have access, this is often mediated through Apple's user-interface in each case - which I suspect you'll find is actually provided by another process within a different sandbox. This means that rogue applications are not hoovering up your data without user-interaction.
In iOS, applications don't have a lot of access to personal data to start with - and certainly not to read SMS (although apps can send using an Apple sanction UI only). They do have access to the contents of the address book, but this is looks likely to change soon.
You think that brute-forcing voicemail PINs would be rather easy to spot - although they likely to have been plenty of weak PINs which were easily guessable with publicly available information.
The proposals for the UK go further: registration of scrap metal dealers and banning of cash payments for scrap, thereby also eliminating huge amounts of tax fraud.
A rather unsavoury fact is that a lot metal theft is perpetrated by employees taking surplus or redundant materials from the employer.
It is no surprise whatsoever. TFS is very much modelled after P4, but P4 is considerably more mature and robust - and it's not even terribly expensive either.
Having implemented just such an application (it has a large model layer shared with the iPad version of the same app), this is not a trivial bit of engineering. JNI provides lots of ways to screw up and debugging across the interface is challenging to say the least.
By FAR the best way to do the development is to get the model and JNI portions working and thoroughly unit tested with a test-harness before going anywhere near any of Google's tools or a device. Since lots of your problems are going to be in C/C++ land, invoking a JVM from native code makes life a lot easier at this stage.
An easy port it was not.
With the possible scenario of Windows Phone 7 being the 3rd successful mobile platform, building the bottom layers of these apps in C#/.Net is looking quite attractive as you can run it on all of the platforms. I assume MonoDroid deals with the consequential.NET VM Native Java boundary crossing.
Clock recovery with firewire audio streams is already pretty damn accurate - and it's entirely possible to achieve sample-accurate presentation. Yamaha's mLAN chipsets had this capability, and I suspect TC's DICE family of devices can too.
Also, extremely low latency is achievable. I can't remember the precise numbers at this juncture, but the limiting factor is the latency hit of a short bus reset. Winding latency down to a couple of milliseconds in each direction is doable.
The limiting factor tends to be the software generating or consuming the audio stream - in practice this usually involves a couple of real-time threads getting woken up perhaps every millisecond to work on a small amount of data - which invariably involves a read, modify (e.g. DSP of some kind) and then write somewhere else - possibly with interleaving for large channels counts.. This starts looking like a pathologically cache-ineffecient workload that doesn't improve much as CPUs get faster.
Slashdot Mirror
No it's not - it's compulsory for devices used to receive real-time broadcast TV content.
And governments on both sides of the political divide have complained about political bias in the past.
In fact, a judge has already thrown a case that did go to court out on the grounds that it was unclear why the damages were set at the level claimed or that they were in any way proportionate to actual damage.
The retailers (usually big supermarkets) are attempting to recover the entire costs of their losses to shoplifting and extra security from those they catch.
The business model of these companies is particularly pernicious, and relies in the main on the defendants being uninformed and under-resourced.
THe company in question here is actually chasing employees of the Citizens' Advice Bureau - the place where these defendants go for help - often because they can't afford a lawyer.
This is a similar strategy to that used by ACS:Law - which has already felt the wrath of the professional regulator for precisely this kind of tactic. It's quite likely that, as suggested, that they sent a few threats too far.
In fairness to London Underground, they have periodically looked at the possibility of providing mobile coverage in stations and trains, but none of the networks were interested in getting involved (and pay for it).
In the grand scheme of things, LU has more pressing needs for its funds.
Actually, it's not - large amounts of it are licensed from 3rd parties - as is the way with all ARM SoC devices - which Samsung then fabricates using its process.
I'd personally consider myself to be a Engineer rather than a programmer (to be precise, I'm a professionally qualified electronics engineer who engages in software and hardware engineering). Cutting the code is a small fraction of what I do, and I tend to do it a variety of programming languages on multiple platforms.
I'm really not in the business of having a dick-waving contest about how hardcore my tools are (an argument that is usually advanced in terms of their lack of features). Instead I expect them to help me along the way.
Modern, commercially developed IDEs genuinely improve my productivity, and I really notice their absence when working for platforms without them.
VxWorks used to - and possibly still does - use a *BSD network stack. Like to hazard a guess how many embedded devices this is in?
It's entirely necessary if using the compiler to drive code completion, syntax highlighting and in-edtior display of compiler errors and warnings. All of these are things are highly interactive and users will notice the lag of GCC getting invoked every time they type a character in their editor. GCC's clunky pre-compiled header support really doesn't help matters.
Of course, as I said earlier, lots of tools have provided this kind of functionality without deep integration of the compiler into the editor, but ultimately to do it properly, you'd still be looking at a great deal of effort to implement the first couple of stages of the compiler pipe-line and get an AST (or equivalent).
There is another excellent reason why the Linux Kernel is staying on GPLv2: a very large proportion of Linux's market share these days is on ARM SoC in mobile devices. There is truckloads of IP in these devices, and right now the chipset vendors are able to keep this closed and compartmentalised.
It's not a case of these chipset vendors wanting to keep their own IP private - often it's not theirs to start with, having been licensed - probably several times already - from other parties.
You can bet that a GPL3 kernel would cause an enormous fork - or even an industry-wide platform switch to something else.
There's also the awkward truth that the vast majority of Linux run-times sold are in mobile phones and other embedded devices and a very, very long way from being 100% open source software.
Precisely who do you think has done a lot of the development on Clang/LLVM over the last few years and contributed it to the wider community?
One of the key design objectives of Clang is that it is highly modular, and implemented in such a way that various compilation stages are self-contained, and have clean APIs and data structures. This allows development tools such as IDEs to link directly against the stages of the compilation pipeline then need to implement syntax highlighting, code completion, refactoring tools and so on.
Apple's XCode does precisely this, and licensing and lack of modularity in the GCC source tree would have been major factors in their choice to support Clang and LLVM development.
The traditional way of implementing these functions in IDEs has been to effectively re-implement the front-end of the compiler (often not completely). This is a big deal when developing in C++ against the STL/Boost/TR1 when you find that code completion can't grok template properly. This is something that XCode and Visual Studio (which takes a similar approach) are both capable of doing.
I'd imagine that under the zero-tolerance policing strategy in many US cities, people engaged in almost all of these activities would simply get arrested for petty criminal offences and cleared off the streets.
The point of anti-social behaviour orders is that they are executed under civil - rather than criminal - law. The idea being that a lower burden of proof is required in court to obtain the order in the first place. In practice, the evidence usually consists of a long record of low-level criminality - a possible example being an individual who is clearly dealing drugs, but who the police have never managed to catch with any.
Of course things on in the realm of the criminal law once the order is breached.
This is what we used to do to pirates in the UK
Execution dock.
It's still there, but has laid unused or quite some time.
I found it distinctly unpleasant to work in too. It is said that one can acclimatise to it though. Be warned though - the evenings are not necessarily cooler than Western room-temperature.
The Japanese have been very successful in curbing demand. I was over in Japan for a week on a business trip last year, and it was interesting to see how they did it. This included absolutely all hand-driers in toilets being switched off, less air-conditioning (room temperature was set for 28C in the office), the business week of large corporations shifted to reduce peak-week-time demand and increase that on the weekend, and a move to more relaxed corporate dress-code - which included in many cases, a small towel attached to the waistband with which to mop off the sweat form the oppressive environment. There were no doubt more measures that I wasn't aware of, but life definitely carries on as normal without power cuts.
Our suspicion is that this state of affairs will become the norm.
I think the point here is that whilst applications do indeed have access, this is often mediated through Apple's user-interface in each case - which I suspect you'll find is actually provided by another process within a different sandbox. This means that rogue applications are not hoovering up your data without user-interaction.
In iOS, applications don't have a lot of access to personal data to start with - and certainly not to read SMS (although apps can send using an Apple sanction UI only). They do have access to the contents of the address book, but this is looks likely to change soon.
Simply weight the toolbox on the way out and again on the way back in.
You think that brute-forcing voicemail PINs would be rather easy to spot - although they likely to have been plenty of weak PINs which were easily guessable with publicly available information.
The proposals for the UK go further: registration of scrap metal dealers and banning of cash payments for scrap, thereby also eliminating huge amounts of tax fraud.
A rather unsavoury fact is that a lot metal theft is perpetrated by employees taking surplus or redundant materials from the employer.
It is no surprise whatsoever. TFS is very much modelled after P4, but P4 is considerably more mature and robust - and it's not even terribly expensive either.
Having implemented just such an application (it has a large model layer shared with the iPad version of the same app), this is not a trivial bit of engineering.
JNI provides lots of ways to screw up and debugging across the interface is challenging to say the least.
By FAR the best way to do the development is to get the model and JNI portions working and thoroughly unit tested with a test-harness before going anywhere near any of Google's tools or a device. Since lots of your problems are going to be in C/C++ land, invoking a JVM from native code makes life a lot easier at this stage.
An easy port it was not.
With the possible scenario of Windows Phone 7 being the 3rd successful mobile platform, building the bottom layers of these apps in C#/.Net is looking quite attractive as you can run it on all of the platforms. I assume MonoDroid deals with the consequential .NET VM Native Java boundary crossing.
Also, extremely low latency is achievable. I can't remember the precise numbers at this juncture, but the limiting factor is the latency hit of a short bus reset. Winding latency down to a couple of milliseconds in each direction is doable.
The limiting factor tends to be the software generating or consuming the audio stream - in practice this usually involves a couple of real-time threads getting woken up perhaps every millisecond to work on a small amount of data - which invariably involves a read, modify (e.g. DSP of some kind) and then write somewhere else - possibly with interleaving for large channels counts.. This starts looking like a pathologically cache-ineffecient workload that doesn't improve much as CPUs get faster.