Society is composed of individuals. And you can expect that statistically there is a certain distribution of behaviour, so in general you can treat those individuals as a mass. And there is the unthinking universe (roads, etc) which the people react to.
The guys who cause traffic jams are outliers in that they drive like epic assholes, but it only takes a few to induce traffic jams because most other people drive in a way that doesn't leave enough slack to absorb the sudden braking and lane changing of epic assholes well. You could theorise that this is because they see a few assholes driving and thereafter drive in a way that stops people "taking advantage" (e.g. jumping queues and merging near the front).
Throw in a few more drivers who leave long gaps, don't brake too quickly, politely let people merge, etc, and they can undo some of the circumstances caused by idiots.
You can still buy USENET services very cheaply from third parties ; ISPs stopped running them because the vast majority of their customers don't even know they exist, let alone used them, and I'd bet that at least 95% of the people who DO use them are doing do for copyright infringement. That puts them firmly in the realms of a cost-centre, rather than a profit maker - no-one selects their ISP based on how great their news servers are. If I ran an ISP, I'd not even bother setting one up.
We have, on average, a lower surface area to volume ratio (we're bigger) and higher metabolism per unit mass (we tend to have more muscle), so it's not really surprising that women can get colder.
Yeah, I bought some of the EU variant, Joylent, and noted that it has that sickly sweet aftertaste I associate with artificial sweeteners. I'd really be entirely happy with them leaving that out.
Ensure is designed as a supplement. There are various groups who find it difficult to consume enough calories - as odd as that sounds. Loss of appetite, or recovery from surgery, or mental disorders that mean you dislike food (I strongly suspected the inventor of Soylent to have one of these but I think it's unfounded). It's not a complete nutritional replacement.
They've even used it for force-feeding hunger strikers at Guantanamo.
We do have interoperability standards : I used to work for the department that specifies them.
They just don't follow them. Case in point : the meta-standard (HL7 v3) that we used for our messaging had a mechanism for not just sending NULL values, but also sending a reason why they were null. (e.g. - the value wasn't measured, etc). The vendor had no truck with that, and was using magic numbers instead (e.g. baby weights of 9999g which is outside the realms of sanity for a newborn). I was tasked with revamping one of the messages. I specified that the proper NULL flavours get used and ditch the magic numbers.
The vendor at this point rolled out the "full system test" clause in their contract, whereby they could charge £N * 10^6 to perform a full system test, because we'd changed the behaviour of one field. They got their way and kept their magic numbers. Other systems expecting messages that met with the conventions of the overall meta-standard for data now have an additional development cost to cope with those magic numbers.
This is the reason for the focus on interoperability over just having standard data structures - it lets vendors continue to use their own proprietary data schemes, and raises a barrier to new participants in the market, not only do you have to implement all the standard interfaces to interoperate, but you probably also have to design in a "quirks" layer to cope with each vendors *special* variations.
Even if it was cheaper to fab right now than NAND, they wouldn't admit it, because they'd be less able to charge a premium price for it. I'm betting that since it has a higher density than NAND and a simpler construction, it will probably end up cheaper than NAND in the longer run.
And DRAM is horribly expensive to fab. So "cheaper than DRAM" leaves a large window.
Right now they are pitching it at the enterprise storage market but that's only smart business - while they ramp up production capacity, get the highest price for it you can.
From the video, it's memristor tech, but everyone is reporting that they are carefully abstaining from letting on what the materials are. Which is fair enough - they want to sew up the market for this stuff as long as possible.
They already have this : it now defaults to "on" by default.
It's DNS level filtering though, so it can be defeated by a simple change of settings. The younger generation are mostly techno-dufuses though, so it probably defeats them.
You see it a lot more if you are searching for other types of content through less than legal means.
If you want to torrent something, you'll get pop-ups of webcam girls, porn sites, etc, that you didn't ask for and weren't in the market for. I imagine for the youth crowd, that's probably the main way they get exposed to it - they want to torrent the latest Iron Man movie, and they get pop-ups for Iron Dick.
Option C: Get a subscription with a newsgroup service for a fraction of the money a porn site will cost you, download as much as you like over a securely encrypted connection, have plausible deniability as to what the content was.
Option D: Get one of those P2P thingamajiganibobs
There are so many ways to get porn on the internet other than the vanilla website-and-a-subscription method.
And porn has the ultimate "Long Tail". There already exists enough digital porn for virtually anyone with a normal-ish kink spectrum to whack off to something new twice a day for the rest of their life. Even if you destroy the porn industry (which this won't, because not every jurisdiction is stupid), people will still trade and use porn, with impunity.
But I read that our banks don't issue them any more because they weren't as widely accepted, because they didn't let you spend funds you didn't have access to.
Re:GPL is a valid option, but overrated
on
On Being Pro-GPL
·
· Score: 1
This is why so many projects require contributors to sign over their copyright when they commit code. They want to retain that control over the licensing centrally.
Copyright assignment is a speedbump in the road that helps to prevent contributions though. Many people are uncomfortable with the notion that their freely contributed work can be taken into a closed project. Many more people are just uncomfortable with the paperwork you need to do.
You only have to look at what happened to OpenOffice when it forked. OpenOffice kept the copyright assignment clause. Now the project is dying in a garden shed in the Apache server farm. LibreOffice ditched copyright assignment and behold, it thrives.
Re:Creative might have been one
on
On Being Pro-GPL
·
· Score: 1
I can confirm that's true. Digging out the driver disk when you reinstalled was a total PITA. A lot of the secret sauce on the card was software, without DRM controls their earlier hardware could probably have been pushed to have most of the features of their later models.
The Linux drivers just work though. I remember booting Linux on that hardware the first time and seeing a colourful SBLive banner in the bootup messages and thinking "Huh. It works!"
You do need special considerations for XML files though - there are several solutions
The weakest solution is to rely on the ability of the target user to spot diffs and correctly merge XML files. And also not to use automatic merging, ever, because the nature of XML files means that conflicting changes may not occur in adjacent lines.
---
The next (and inadequate) solution is to order the XML consistently - you can do this in your diff tool, or you can write your tools to produce a reliably ordered file in the first place.
Many tools that work on XML files exhibit what I call "juggling" - the elements and attributes change order when you change the value of them or their siblings, because the software is directly using the DOM to manipulate the file - and does this by creating new objects and removing the old ones from the collection. This is a real PITA for text-based diff tools because not all the changes will even conflict with each other (element sequences are often spread across multiple lines, more so if you put attributes on their own line to enhance the ability to merge).
So, you can either write your code to write a consistent order - usually by serializing a fresh XML stream from a model when you write the file.
Or you can add a layer that re-orders the document when you diff it - many of the available diff tools will let you do this. For some files, I used to write an XSLT sheet (to re-order elements consistently). For attributes, I wrote an extra option for Tidy that sorts attributes - doing that plus laying them out on separate lines is sufficient for many files. I've gone as far as writing custom tools that unpack HTML written into an attribute (with all the escape sequences that entails) into a CDATA section for clarity, runs it through Tidy, and then repacks everything after you're done.
--- Intermediate : I've thought of taking this a step further and converting the XML to a directory tree of text files designed to merge well, principally to make things clearer for end-users who currently have the kind of diff-tool-plus-converter described above but still occasionally make merge errors. --- The next step is to write tools to specifically diff your model. This is probably a bridge too far for most developers, because we have the kind of brain that can abstract a text representation of the model and map it to the actual model that will be created. For end users, it may well be advisable.
Diff / merge tools are a field that need more work - currently the main users are developers who can cope with them being a bit immature. But we will increasingly see collaborative tools based on the kinds of version control that we take for granted, and normal users will need to be able to do this stuff too.
> no more free development for.NET 4.6 with visual studio
Community supports the vast majority of useful features... and really, what's the problem with it costing money if you want more than 5 developers or have a $1M+ turnover company? You're still allowed Community if you're using it for classroom learning, academic research, or open-source development.
If you're working for a company that presumably makes money from writing software (in one way or another) is it really so bad to give some of that money to a company that helped you do that with their product? If you hire a developer, their salary is far more than the $1,119 it will cost you for VS Pro with MSDN ; do you really want to waste their time by making them write their code with a text editor and build it with just the.NET SDK tools?
I usually prefer SharpDevelop for my.NET dev but I've not done any in a long time - I'd be inclined to give Visual Studio a go, even if I've found it's prior iterations to be far too handholding and patriarchal.
It basically excludes new players from the market. Only the big firms have the resources to go through all that compliance paperwork. Which means the only people left are the lying, cheating, scum that caused the problem in the first place.
This has only fostered a risk-averse mentality that chokes every aspect of government and big business. No wonder it's the small firms that have the reputation for innovation - it's because they still have their innocence and aren't wasting 95% of their energy looking over their shoulder and checking up on things to cover their asses.
They already have by far the best remote-desktop service. [1]
A screen-recording tool just needs to be able to serialize the stream that RDP uses to disk - very efficient, very conservative of space. I can't believe that the Linux RDP tools don't already do this.
[1] "Best" as in - works, works well, has low latency and the tools are easy to get hold of and set up.
NX or whatever it has evolved into was very good in terms of performance, raw X11 blows over a network (which is ironic given that's part of it's design brief and one of the principle things holding back the Linux desktop environment for so long). Neither are easy to set up or use.
They did something similar, put a couple of specific constants, into the Dual_EC_DRBG random number generator. It was later shown that they amounted to a skeleton key - if you knew the numbers used to derive the constants, you could predict the future output of a given RNG instance with only a small amount of sample data. So any encryption based on Dual_EC_DRBG could be considered to be broken by the NSA (somewhat conveniently, in a way that only the NSA could actually prove).
Despite the poor performance of this algorithm which lead most implementers to ignore it, it managed to end up as the default in the product of one of the most trusted vendors, RSA. There was speculation that the NSA bribed them to make this design choice. [1]
[1] The only comment on that story makes the same point - that the NSA, in the past, had reinforced weaknesses in DES. In the light of the later evidence about Dual_EC_DRBG, that may bear further examination - if the change was the tweaking of constants, it's entirely possible that this reinforced the standard for everyone but the NSA.
Slashdot Mirror
It's like Seldon's Psychohistory :
Society is composed of individuals. And you can expect that statistically there is a certain distribution of behaviour, so in general you can treat those individuals as a mass. And there is the unthinking universe (roads, etc) which the people react to.
The guys who cause traffic jams are outliers in that they drive like epic assholes, but it only takes a few to induce traffic jams because most other people drive in a way that doesn't leave enough slack to absorb the sudden braking and lane changing of epic assholes well. You could theorise that this is because they see a few assholes driving and thereafter drive in a way that stops people "taking advantage" (e.g. jumping queues and merging near the front).
Throw in a few more drivers who leave long gaps, don't brake too quickly, politely let people merge, etc, and they can undo some of the circumstances caused by idiots.
You can still buy USENET services very cheaply from third parties ; ISPs stopped running them because the vast majority of their customers don't even know they exist, let alone used them, and I'd bet that at least 95% of the people who DO use them are doing do for copyright infringement. That puts them firmly in the realms of a cost-centre, rather than a profit maker - no-one selects their ISP based on how great their news servers are. If I ran an ISP, I'd not even bother setting one up.
We have, on average, a lower surface area to volume ratio (we're bigger) and higher metabolism per unit mass (we tend to have more muscle), so it's not really surprising that women can get colder.
Yeah, I bought some of the EU variant, Joylent, and noted that it has that sickly sweet aftertaste I associate with artificial sweeteners. I'd really be entirely happy with them leaving that out.
Ensure is designed as a supplement. There are various groups who find it difficult to consume enough calories - as odd as that sounds. Loss of appetite, or recovery from surgery, or mental disorders that mean you dislike food (I strongly suspected the inventor of Soylent to have one of these but I think it's unfounded). It's not a complete nutritional replacement.
They've even used it for force-feeding hunger strikers at Guantanamo.
Presumably you'd tan with chlorophyll instead of melanin. Captain Kirk would have a field day.
The EU equivalent, Joylent, costs about €6 a day.
Pre-prepared bottles are the real WTF here - they're heavier, more wasteful.
The guy lived on it exclusively for a few months and had regular blood tests to make sure his health was maintained.
Tyson, is that you??
We do have interoperability standards : I used to work for the department that specifies them.
They just don't follow them. Case in point : the meta-standard (HL7 v3) that we used for our messaging had a mechanism for not just sending NULL values, but also sending a reason why they were null. (e.g. - the value wasn't measured, etc). The vendor had no truck with that, and was using magic numbers instead (e.g. baby weights of 9999g which is outside the realms of sanity for a newborn). I was tasked with revamping one of the messages. I specified that the proper NULL flavours get used and ditch the magic numbers.
The vendor at this point rolled out the "full system test" clause in their contract, whereby they could charge £N * 10^6 to perform a full system test, because we'd changed the behaviour of one field. They got their way and kept their magic numbers. Other systems expecting messages that met with the conventions of the overall meta-standard for data now have an additional development cost to cope with those magic numbers.
This is the reason for the focus on interoperability over just having standard data structures - it lets vendors continue to use their own proprietary data schemes, and raises a barrier to new participants in the market, not only do you have to implement all the standard interfaces to interoperate, but you probably also have to design in a "quirks" layer to cope with each vendors *special* variations.
Cost : "between NAND and DRAM."
Even if it was cheaper to fab right now than NAND, they wouldn't admit it, because they'd be less able to charge a premium price for it. I'm betting that since it has a higher density than NAND and a simpler construction, it will probably end up cheaper than NAND in the longer run.
And DRAM is horribly expensive to fab. So "cheaper than DRAM" leaves a large window.
Right now they are pitching it at the enterprise storage market but that's only smart business - while they ramp up production capacity, get the highest price for it you can.
From the video, it's memristor tech, but everyone is reporting that they are carefully abstaining from letting on what the materials are. Which is fair enough - they want to sew up the market for this stuff as long as possible.
It's going to cost more than NAND flash.
But it would make a GREAT cache for spinning rust. None of the longevity problems of NAND, 1,000 times faster. Ka-chow.
They already have this : it now defaults to "on" by default.
It's DNS level filtering though, so it can be defeated by a simple change of settings. The younger generation are mostly techno-dufuses though, so it probably defeats them.
You see it a lot more if you are searching for other types of content through less than legal means.
If you want to torrent something, you'll get pop-ups of webcam girls, porn sites, etc, that you didn't ask for and weren't in the market for. I imagine for the youth crowd, that's probably the main way they get exposed to it - they want to torrent the latest Iron Man movie, and they get pop-ups for Iron Dick.
Option C: Get a subscription with a newsgroup service for a fraction of the money a porn site will cost you, download as much as you like over a securely encrypted connection, have plausible deniability as to what the content was.
Option D: Get one of those P2P thingamajiganibobs
There are so many ways to get porn on the internet other than the vanilla website-and-a-subscription method.
And porn has the ultimate "Long Tail". There already exists enough digital porn for virtually anyone with a normal-ish kink spectrum to whack off to something new twice a day for the rest of their life. Even if you destroy the porn industry (which this won't, because not every jurisdiction is stupid), people will still trade and use porn, with impunity.
In this country it used to be that under-18 year olds could only get a Solo or card, which a lot of places used as a basic age check.
But I read that our banks don't issue them any more because they weren't as widely accepted, because they didn't let you spend funds you didn't have access to.
This is why so many projects require contributors to sign over their copyright when they commit code. They want to retain that control over the licensing centrally.
Copyright assignment is a speedbump in the road that helps to prevent contributions though. Many people are uncomfortable with the notion that their freely contributed work can be taken into a closed project. Many more people are just uncomfortable with the paperwork you need to do.
You only have to look at what happened to OpenOffice when it forked. OpenOffice kept the copyright assignment clause. Now the project is dying in a garden shed in the Apache server farm. LibreOffice ditched copyright assignment and behold, it thrives.
I can confirm that's true. Digging out the driver disk when you reinstalled was a total PITA. A lot of the secret sauce on the card was software, without DRM controls their earlier hardware could probably have been pushed to have most of the features of their later models.
The Linux drivers just work though. I remember booting Linux on that hardware the first time and seeing a colourful SBLive banner in the bootup messages and thinking "Huh. It works!"
Not to shoot out of them. To produce images in them.
At least one piece of science fiction I've read has eyeball lasing cells in it. Now it seems less fictional.
You do need special considerations for XML files though - there are several solutions
The weakest solution is to rely on the ability of the target user to spot diffs and correctly merge XML files. And also not to use automatic merging, ever, because the nature of XML files means that conflicting changes may not occur in adjacent lines.
---
The next (and inadequate) solution is to order the XML consistently - you can do this in your diff tool, or you can write your tools to produce a reliably ordered file in the first place.
Many tools that work on XML files exhibit what I call "juggling" - the elements and attributes change order when you change the value of them or their siblings, because the software is directly using the DOM to manipulate the file - and does this by creating new objects and removing the old ones from the collection. This is a real PITA for text-based diff tools because not all the changes will even conflict with each other (element sequences are often spread across multiple lines, more so if you put attributes on their own line to enhance the ability to merge).
So, you can either write your code to write a consistent order - usually by serializing a fresh XML stream from a model when you write the file.
Or you can add a layer that re-orders the document when you diff it - many of the available diff tools will let you do this. For some files, I used to write an XSLT sheet (to re-order elements consistently). For attributes, I wrote an extra option for Tidy that sorts attributes - doing that plus laying them out on separate lines is sufficient for many files. I've gone as far as writing custom tools that unpack HTML written into an attribute (with all the escape sequences that entails) into a CDATA section for clarity, runs it through Tidy, and then repacks everything after you're done.
---
Intermediate : I've thought of taking this a step further and converting the XML to a directory tree of text files designed to merge well, principally to make things clearer for end-users who currently have the kind of diff-tool-plus-converter described above but still occasionally make merge errors.
---
The next step is to write tools to specifically diff your model. This is probably a bridge too far for most developers, because we have the kind of brain that can abstract a text representation of the model and map it to the actual model that will be created. For end users, it may well be advisable.
Diff / merge tools are a field that need more work - currently the main users are developers who can cope with them being a bit immature. But we will increasingly see collaborative tools based on the kinds of version control that we take for granted, and normal users will need to be able to do this stuff too.
> no more free development for .NET 4.6 with visual studio
Community supports the vast majority of useful features... and really, what's the problem with it costing money if you want more than 5 developers or have a $1M+ turnover company? You're still allowed Community if you're using it for classroom learning, academic research, or open-source development.
If you're working for a company that presumably makes money from writing software (in one way or another) is it really so bad to give some of that money to a company that helped you do that with their product? If you hire a developer, their salary is far more than the $1,119 it will cost you for VS Pro with MSDN ; do you really want to waste their time by making them write their code with a text editor and build it with just the .NET SDK tools?
I usually prefer SharpDevelop for my .NET dev but I've not done any in a long time - I'd be inclined to give Visual Studio a go, even if I've found it's prior iterations to be far too handholding and patriarchal.
And the most depressing thing about this?
It basically excludes new players from the market. Only the big firms have the resources to go through all that compliance paperwork. Which means the only people left are the lying, cheating, scum that caused the problem in the first place.
This has only fostered a risk-averse mentality that chokes every aspect of government and big business. No wonder it's the small firms that have the reputation for innovation - it's because they still have their innocence and aren't wasting 95% of their energy looking over their shoulder and checking up on things to cover their asses.
They already have by far the best remote-desktop service. [1]
A screen-recording tool just needs to be able to serialize the stream that RDP uses to disk - very efficient, very conservative of space. I can't believe that the Linux RDP tools don't already do this.
[1] "Best" as in - works, works well, has low latency and the tools are easy to get hold of and set up.
NX or whatever it has evolved into was very good in terms of performance, raw X11 blows over a network (which is ironic given that's part of it's design brief and one of the principle things holding back the Linux desktop environment for so long). Neither are easy to set up or use.
Stronger for everyone except them, perhaps.
They did something similar, put a couple of specific constants, into the Dual_EC_DRBG random number generator. It was later shown that they amounted to a skeleton key - if you knew the numbers used to derive the constants, you could predict the future output of a given RNG instance with only a small amount of sample data. So any encryption based on Dual_EC_DRBG could be considered to be broken by the NSA (somewhat conveniently, in a way that only the NSA could actually prove).
Despite the poor performance of this algorithm which lead most implementers to ignore it, it managed to end up as the default in the product of one of the most trusted vendors, RSA. There was speculation that the NSA bribed them to make this design choice. [1]
Unsurprisingly, it was withdrawn from the standard in 2014.
[1] The only comment on that story makes the same point - that the NSA, in the past, had reinforced weaknesses in DES. In the light of the later evidence about Dual_EC_DRBG, that may bear further examination - if the change was the tweaking of constants, it's entirely possible that this reinforced the standard for everyone but the NSA.