If the claim is false, it could be a felony in Minnesota, where the student attended school. This is according to the collection of state regulations at http://www.firstamendmentcente... . For Minnesota, the relevant statutes are Minn. Stat. 609.765 and Minn. Stat. 609.77. The young man could get up to a year in jail and a fine of up to $3000.
That's much like the old "webbug" problem, which relied on one pixel sized, transparent images downloaded from the desired upsteam advertiging and usage This sort of behavior was well described by the Electronic Frontier Foundation at https://w2.eff.org/Privacy/Mar.... That problem still exists.
The failure to reject such default optimization on the purely privacy basis is a troubling one. It means that, for example, I can track the location of people who read my email sent through anonymizing services, simply because they hover over the link to my server.
"Lynx" is quite good for detangling bad websites, and for reviewing privacy negligent or security suspicious websites: it's a purely text-only browser and does not run Javascript at all.
> It is interesting to see not only the technical influence, but the design philosophy inherited from the Skype acquisition:
It's consistent with Skype: it was hardly unique to them. It's inherent in Microsoft's registration models, their "Trusted Computing" encryption key architecture, and the very poor security of MS File Sharing itself. You _cannot_ use Powershell to administer your host if you block sharing your entire C: drive as the hidden share \\hostname\c$. A security model that says "to use administrations tools, I must expose my entire filesystem" is not a good approach to security.
> Copyright granted pretty much one thing, and one thing only. Copyright guaranteed that IF - that really big, huge IF - anyone should make a profit off of any given work, then the AUTHOR should share in that profit.
I;m afraid you're looking at a very skewed history of copyright. Many of the earliest copyrights were about editorial control of the published documents, particularly the Bible. There was a very real fear that later Bibles would make free translations for local cultural or religious beliefs, and it was a completely understandable fear. There were, and are, serious historical arguments about whether Jesus had siblings, about the infamous quote "thou shalt not suffer a witch to live", and whether other documents about Mary Magdalen sould have been included in the Bible. Leaving the copyright open for editing by local printers could have encouraged even more schisms among Christians, especially after the printing press made local variants easier to publish.
I agree with you. I was trying to point out that most people won't care about the subtle distinctions, and will insist that they are they same even when there are clear historical, architectural, and API differences between them.
And Linux is not UNIX. But it was designed for compatibility, using most of the same system architecture and API's, and software is designed to be compatible between them.
Or at least, it was increasingly compatible until systemd came along.
A battery with at least 2 full phone charges in it fits well in a briefcase or backpack, and allows remote tethering for others in a crisis or when the corporate or public wifi is misconfigured. There are dozens of excellent external batteries, many of them very robust or even with solar recharge capacity. These can save you from having to lend your phone to someone else who ran out of charge, or being tethered while your phone recharges.
Please excuse me: on the way up, hey heterodyne off the other HFT traders and "real" investors increasing prices and also engaging in short term transactions, not off the shortsellers.
But the high frequency trading purchases and sales are, effectively, technologically assisted "pump and dump". They don't hold most stocks for even 60 seconds, and rely on the "forgiveness" of the puchasing system to discard trades they don't ever actually complete, to avoid transaction fees and to discard trades which might lose them money. The positive feedback of one HFT making a few puchases bumps a price incrementally, the next HFT buys some on speculation, the first sells and buys more, and they heterodyne off each other and the other shortsellers until the stock price hits a cap imposed by the other, slower, negative feedback in the market. Then they both shortsell on the way down, draining the potential profits from other, longer term investors on the way up and the way down.
HFT makes its money, not off of investment, but off of pure "arbitrage", off the churn in the market. It's quite destructive and drains the profit right out of normal buying and selling.
Larger. Without getting into company details I'd prefer not to share, we support enterprise applications in house, and are the "go-to" internal consultants for development projects. We also integrate our systems with partners, and clients, to ensure that we can work with each other's workflow and API's. It's been very positive, and we've been able to effectively swap employees with partners and clients on a few occasions to improve both companies. As much of the software is "fee as in speech" as I can arrange, for business and political reasons, and most of the remainder is open source.
> I could have told him that too...enterprise users don't care about cost really.
Oh, my, but we do.
> t's all done under a financial penalty SLA (service level agreement). We can't skip on this as our clients already have us locked into contract
Then I suggest you revisit most open source and free software companies. Uber is a different situation: they're filling a market niche that the cab companies had a very effective cartel for. But I'm _personally_ doing quite well with free software and open source software: Freemium _for closed source products has never worked well.
Any moderately capable fisherman who's used a fly fishing rod should be able to make a reasonable accurate cast to drop the lead "sinker" through the path of the propellors, with the monofilament dragged with it, fouling the rotors or even bodily hooking the drone. It also gives you the choice of cutting the line and walking away, or following the line to the crashed drone even if doesn't crash as close as you might wish.
There are some modest risks of dragging monofilament around people's yards, and of hitting a bystander with a sinker, but it seems safer than firing faster projectiles in an inhabited area.
I'm afraid that a great deal of "web development" has become automated over time and done by other personnel. It's often cheaper and far, far faster for most sites to reduce their toolkits to a few well supported technologies and stop hosting their own storage, their own DNS, their own mail servers, and yes, their own "web server" farmss. I've helped various partners and clients reduce their developer head count by a great deal by discarding the in-house, only one developer in their own team knows it, proprietary technologies in favor of less flexible but far more stable and scalable technologies.
Jest yesterday, I spent the day going over available technologies pulled off of Google web searches by an eager web developer for some critical web services. I did show their manager the infamous "MongoDB is Webscale" video, to illustrate for their supervisor why adding "secret sauce" of exciting, new, in-house technologies can be destructive.
There are actually uses. a robust virtualization server can support an SDN to set up a completely internal testing network. This can be far faster, and far cheaper, than bringing in new switches and new cabling and new configuration environments.
> No... The only people that can touch the server are people that are hand picked and trusted.
You seem to be _extremely_ optimistic about most security enviromments. I don't deny that your guidelines are sensible and appropriate, or that they are rigorous and thoughtful. But they're violated, in practice and in policy even in most so-called "secure" environments. As most networks grow and mature, there are extremely frequent holes drilled and policies violated for the ease and convenience of the administrators and developers, for access by those who pay salaries, Even when technologies exist to provide access more safely and rigorously, the attempt to turn off the favorite access tool of a critical developer is the sort of thing that gets people fired.
Edward Snowden is actually a good example of where policy was being ignored, namely the policy for the NSA not to commit criminal acts against US citizens. He _repeatedly_ reported criminal abuse by the NSA to his own superiors, and tried to use the chain of command to address ongoing criminal activity. He was stonewalled, and repaid the trust placed in him by very correctly whistleblowing. The man deserves a pardon, a medal, and to be on the staff of the US representative to the UN Security Council. His was precisely the kind of case where human involvement in security paid enormous dividends over blind technological obedience.
Stuxnet was a different situation. It's well known that in a large group of employees, some of them will be security careless, and that a significant number of them will violate the security principles you advocate. They're good principles, but there are going to be violations of them. It's why the most effective security I've worked with is multi-layer: it includes robust backups, regular upgrades, security scans, changes in access credentials, access auditing, sensible password policy, and other tools.
And then you leave the root keys, and the details on how to access and configure the server, on a trivially accessable wiki, especially with root keys stored unencrypted by developers and admins by policy "because we trust the people we work with" and "because we have a firewall".
I can attest to this. It's usually a matter of confusion by the managers or corporate attorneys. In other cases it's pure greed: they wish to proprietize the basic product of others and sell their added features, their "secret sauce", at a premium. This was the core of many, many failed dotcoms, and I've seen it at the core of development teams who provided no benefit to the company in the long run. But they did manage to defend bureaucratic turf and departmental resources from review by essentially hiding the genuine sources of their code.
> Seeing your code work on another computer tells you nothing at all
Oh, it can be quite useful. "Another computer" often means "a system that has not had the interesting local undocumented developer modifications that have replaced basic perl modules with too-new or too-old CPAN dependencies". Or it can mean systems that have not had the latest software update with the new regression in a system library, or a system where a developer has not been tuning sysctl parameters and SELinux. I've run into all of those, in the last week.
I'm afraid I'm unable to post some of my best failures, they're too personally identifiable to me or to a client or colleague. I will mention my most galling, most frequent style of bug in the last five years: It's the complete refusal to bundle software. To just "compile from source" or haphazardly integrate components from CPAN, from pip, from maven, from apt or RPM or other sourceforge or github or any unmaintained, untested repository scattered anywhere in the world without the slightest dependency testing or component verification. Cleaning up the mess is paying a great deal of my salary right now.
Oddly, the last time I _chose_ to use Firefox was several years ago. I occassionally choose to use Intenet Explorer to get MS updates, and to work with corporate sites that insist on "Microsoft only" features. But I discarded Firefox in favor of Chrome some time ago, simply for the better performance and compatibility with more websites.
I've gotten random links to porn. I'm afraid I also get social email from colleagues and clients who say "Hey, check this out". And I've also had clients who run pornography and escort services. The smaller ones don't always pay their bills, but adult traffic is a _very_ big provider and consumer of high bandwidth Intenet traffic, so they're a difficult market to ignore.
I had to look deeper to see that you are correct. There _have_ been several NASA published designs using microwaves or other EM for ordinary thrust, I'm afraid I thought the original article concerned one of those.
On review, as I mentioned elsewhere, I'll bet that this is really a "Dean Drive". The Dean Drive never worked well outside the designer's workshop, was never tested properly with a basic "pendulum" test, and seems to have been a basic "oscillation thruster": it interacted with the floor under it to provide net thrust. That would mean the system is not really "sealed", it's interacting with its environment in some subtle way.
From the description at http://motherboard.vice.com/re..., I'd guess EM interaction with the walls of the stainless steel vacuum chamber. And one of hte people I'd want to review the experiment would be James Randi, who's been helping debunk "mysterious mental force" claims for decades, and has a professional magician's eye for misdirection and sleight of hand.
Slashdot Mirror
If the claim is false, it could be a felony in Minnesota, where the student attended school. This is according to the collection of state regulations at http://www.firstamendmentcente... . For Minnesota, the relevant statutes are Minn. Stat. 609.765 and Minn. Stat. 609.77. The young man could get up to a year in jail and a fine of up to $3000.
That's much like the old "webbug" problem, which relied on one pixel sized, transparent images downloaded from the desired upsteam advertiging and usage This sort of behavior was well described by the Electronic Frontier Foundation at https://w2.eff.org/Privacy/Mar.... That problem still exists.
The failure to reject such default optimization on the purely privacy basis is a troubling one. It means that, for example, I can track the location of people who read my email sent through anonymizing services, simply because they hover over the link to my server.
"Lynx" is quite good for detangling bad websites, and for reviewing privacy negligent or security suspicious websites: it's a purely text-only browser and does not run Javascript at all.
> It is interesting to see not only the technical influence, but the design philosophy inherited from the Skype acquisition:
It's consistent with Skype: it was hardly unique to them. It's inherent in Microsoft's registration models, their "Trusted Computing" encryption key architecture, and the very poor security of MS File Sharing itself. You _cannot_ use Powershell to administer your host if you block sharing your entire C: drive as the hidden share \\hostname\c$. A security model that says "to use administrations tools, I must expose my entire filesystem" is not a good approach to security.
> Copyright granted pretty much one thing, and one thing only. Copyright guaranteed that IF - that really big, huge IF - anyone should make a profit off of any given work, then the AUTHOR should share in that profit.
I;m afraid you're looking at a very skewed history of copyright. Many of the earliest copyrights were about editorial control of the published documents, particularly the Bible. There was a very real fear that later Bibles would make free translations for local cultural or religious beliefs, and it was a completely understandable fear. There were, and are, serious historical arguments about whether Jesus had siblings, about the infamous quote "thou shalt not suffer a witch to live", and whether other documents about Mary Magdalen sould have been included in the Bible. Leaving the copyright open for editing by local printers could have encouraged even more schisms among Christians, especially after the printing press made local variants easier to publish.
I agree with you. I was trying to point out that most people won't care about the subtle distinctions, and will insist that they are they same even when there are clear historical, architectural, and API differences between them.
And Linux is not UNIX. But it was designed for compatibility, using most of the same system architecture and API's, and software is designed to be compatible between them.
Or at least, it was increasingly compatible until systemd came along.
A battery with at least 2 full phone charges in it fits well in a briefcase or backpack, and allows remote tethering for others in a crisis or when the corporate or public wifi is misconfigured. There are dozens of excellent external batteries, many of them very robust or even with solar recharge capacity. These can save you from having to lend your phone to someone else who ran out of charge, or being tethered while your phone recharges.
Thank you, I misused that term there.
Please excuse me: on the way up, hey heterodyne off the other HFT traders and "real" investors increasing prices and also engaging in short term transactions, not off the shortsellers.
But the high frequency trading purchases and sales are, effectively, technologically assisted "pump and dump". They don't hold most stocks for even 60 seconds, and rely on the "forgiveness" of the puchasing system to discard trades they don't ever actually complete, to avoid transaction fees and to discard trades which might lose them money. The positive feedback of one HFT making a few puchases bumps a price incrementally, the next HFT buys some on speculation, the first sells and buys more, and they heterodyne off each other and the other shortsellers until the stock price hits a cap imposed by the other, slower, negative feedback in the market. Then they both shortsell on the way down, draining the potential profits from other, longer term investors on the way up and the way down.
HFT makes its money, not off of investment, but off of pure "arbitrage", off the churn in the market. It's quite destructive and drains the profit right out of normal buying and selling.
Larger. Without getting into company details I'd prefer not to share, we support enterprise applications in house, and are the "go-to" internal consultants for development projects. We also integrate our systems with partners, and clients, to ensure that we can work with each other's workflow and API's. It's been very positive, and we've been able to effectively swap employees with partners and clients on a few occasions to improve both companies. As much of the software is "fee as in speech" as I can arrange, for business and political reasons, and most of the remainder is open source.
The Human Genome Project, assembling work from thousands of researchers, developers, and technicians worldwide had hundreds of authors.
http://www.nature.com/nature/j...
It can make sense in such a large project to list as many of the contributors as possible.
> I could have told him that too...enterprise users don't care about cost really.
Oh, my, but we do.
> t's all done under a financial penalty SLA (service level agreement). We can't skip on this as our clients already have us locked into contract
Then I suggest you revisit most open source and free software companies. Uber is a different situation: they're filling a market niche that the cab companies had a very effective cartel for. But I'm _personally_ doing quite well with free software and open source software: Freemium _for closed source products has never worked well.
Any moderately capable fisherman who's used a fly fishing rod should be able to make a reasonable accurate cast to drop the lead "sinker" through the path of the propellors, with the monofilament dragged with it, fouling the rotors or even bodily hooking the drone. It also gives you the choice of cutting the line and walking away, or following the line to the crashed drone even if doesn't crash as close as you might wish.
There are some modest risks of dragging monofilament around people's yards, and of hitting a bystander with a sinker, but it seems safer than firing faster projectiles in an inhabited area.
I'm afraid that a great deal of "web development" has become automated over time and done by other personnel. It's often cheaper and far, far faster for most sites to reduce their toolkits to a few well supported technologies and stop hosting their own storage, their own DNS, their own mail servers, and yes, their own "web server" farmss. I've helped various partners and clients reduce their developer head count by a great deal by discarding the in-house, only one developer in their own team knows it, proprietary technologies in favor of less flexible but far more stable and scalable technologies.
Jest yesterday, I spent the day going over available technologies pulled off of Google web searches by an eager web developer for some critical web services. I did show their manager the infamous "MongoDB is Webscale" video, to illustrate for their supervisor why adding "secret sauce" of exciting, new, in-house technologies can be destructive.
There are actually uses. a robust virtualization server can support an SDN to set up a completely internal testing network. This can be far faster, and far cheaper, than bringing in new switches and new cabling and new configuration environments.
> No... The only people that can touch the server are people that are hand picked and trusted.
You seem to be _extremely_ optimistic about most security enviromments. I don't deny that your guidelines are sensible and appropriate, or that they are rigorous and thoughtful. But they're violated, in practice and in policy even in most so-called "secure" environments. As most networks grow and mature, there are extremely frequent holes drilled and policies violated for the ease and convenience of the administrators and developers, for access by those who pay salaries, Even when technologies exist to provide access more safely and rigorously, the attempt to turn off the favorite access tool of a critical developer is the sort of thing that gets people fired.
Edward Snowden is actually a good example of where policy was being ignored, namely the policy for the NSA not to commit criminal acts against US citizens. He _repeatedly_ reported criminal abuse by the NSA to his own superiors, and tried to use the chain of command to address ongoing criminal activity. He was stonewalled, and repaid the trust placed in him by very correctly whistleblowing. The man deserves a pardon, a medal, and to be on the staff of the US representative to the UN Security Council. His was precisely the kind of case where human involvement in security paid enormous dividends over blind technological obedience.
Stuxnet was a different situation. It's well known that in a large group of employees, some of them will be security careless, and that a significant number of them will violate the security principles you advocate. They're good principles, but there are going to be violations of them. It's why the most effective security I've worked with is multi-layer: it includes robust backups, regular upgrades, security scans, changes in access credentials, access auditing, sensible password policy, and other tools.
And then you leave the root keys, and the details on how to access and configure the server, on a trivially accessable wiki, especially with root keys stored unencrypted by developers and admins by policy "because we trust the people we work with" and "because we have a firewall".
> Why do word processors need new features at this point?
Unicode for multiple languages, and the desire to embed graphics.
I can attest to this. It's usually a matter of confusion by the managers or corporate attorneys. In other cases it's pure greed: they wish to proprietize the basic product of others and sell their added features, their "secret sauce", at a premium. This was the core of many, many failed dotcoms, and I've seen it at the core of development teams who provided no benefit to the company in the long run. But they did manage to defend bureaucratic turf and departmental resources from review by essentially hiding the genuine sources of their code.
> Seeing your code work on another computer tells you nothing at all
Oh, it can be quite useful. "Another computer" often means "a system that has not had the interesting local undocumented developer modifications that have replaced basic perl modules with too-new or too-old CPAN dependencies". Or it can mean systems that have not had the latest software update with the new regression in a system library, or a system where a developer has not been tuning sysctl parameters and SELinux. I've run into all of those, in the last week.
I'm afraid I'm unable to post some of my best failures, they're too personally identifiable to me or to a client or colleague. I will mention my most galling, most frequent style of bug in the last five years: It's the complete refusal to bundle software. To just "compile from source" or haphazardly integrate components from CPAN, from pip, from maven, from apt or RPM or other sourceforge or github or any unmaintained, untested repository scattered anywhere in the world without the slightest dependency testing or component verification. Cleaning up the mess is paying a great deal of my salary right now.
Oddly, the last time I _chose_ to use Firefox was several years ago. I occassionally choose to use Intenet Explorer to get MS updates, and to work with corporate sites that insist on "Microsoft only" features. But I discarded Firefox in favor of Chrome some time ago, simply for the better performance and compatibility with more websites.
I've gotten random links to porn. I'm afraid I also get social email from colleagues and clients who say "Hey, check this out". And I've also had clients who run pornography and escort services. The smaller ones don't always pay their bills, but adult traffic is a _very_ big provider and consumer of high bandwidth Intenet traffic, so they're a difficult market to ignore.
I had to look deeper to see that you are correct. There _have_ been several NASA published designs using microwaves or other EM for ordinary thrust, I'm afraid I thought the original article concerned one of those.
On review, as I mentioned elsewhere, I'll bet that this is really a "Dean Drive". The Dean Drive never worked well outside the designer's workshop, was never tested properly with a basic "pendulum" test, and seems to have been a basic "oscillation thruster": it interacted with the floor under it to provide net thrust. That would mean the system is not really "sealed", it's interacting with its environment in some subtle way.
From the description at http://motherboard.vice.com/re..., I'd guess EM interaction with the walls of the stainless steel vacuum chamber. And one of hte people I'd want to review the experiment would be James Randi, who's been helping debunk "mysterious mental force" claims for decades, and has a professional magician's eye for misdirection and sleight of hand.