But facebook can already do that - this isn't related to what facebook may or may not be doing behind the scenes.
Any third party with facial recognition software can also do this, but they'll need access to the people's profiles first.
And that's where a major change may be. Say you 'friend' a certain festival organizer because hey, if you friend them, you can keep updated on developments, or you get a discount, or whatever. So you go to that festival, you have a good time, you also - unfortunately - get shitfaced. The festival organizer takes pictures during the event, and posts them online. Suddenly, you're not just some random guy in a festival picture that, albeit not impossible to find, requires a certain level of effort. No, now you're a tagged guy, and one needs but click through to get to your profile.
Now, yes.. you -chose- to friend the festival organizers., and by going to the festival you, implicitly or explicitly, agreed to photos of the festival to be used in publication, and so forth and so on. The question is, did you knowingly and willingly also allow them to - automatically or otherwise - tag you in those photos? The "knowingly" would certainly need scrutinizing, as the article seems to imply that facebook enabled by default and didn't particular let you know (I'm sure it can be found somewhere and you're supposed to check that every 10 minutes for whatever consent-who-needs-consent change they implemented this time) - and with it, the "willingly" part.
If you'd read the KickStarter page, you would've come across this part:
Also, I need to make molds and aluminum extrusion dies to reduce manufacturing costs. I machined my original HexBright Prime out of solid hex-bar stock, but if I can have the bar stock made with a hole in the middle I save a ton of time and money
Which pretty much addresses half your post.
Your corrosion and wiring concerns are valid enough, but I'm confident that both will be treated appropriately. My only concern is actually with regard to the button (I'd like a button of the same type used on cameras so that a soft press can just turn it on for as long as I hold the button there, and a full button press actually switches) and aftermarket capabilities. The former being a use concern, the other being a versatility concern.
As for features not being 'the problem with flashlights', that depends on who you ask. I have a MagLite, it's just fine, and thanks to its bulk I can cave in somebody's skull with it - which makes it popular among guards and such. But it's still not going to be programmable, and it only has 3 modes (as mentioned above: off, not quite bright enough, and way too bright).
Walmart obviously shows 1 hit on their site.. how many more do you need?
I've seen them aplenty in the U.S., they're typically on the racks near the registers.
They're a bit more rare in the EU, though. Plenty of websites that sell them, but step into a local Aldi or whatever and you may not have the luck of seeing them there.
That's interesting, I guess, but that sort of thing is trivial to reverse engineer if you wanted to change the design.
Absolutely. But it's far more trivial to load a CAD file than to re-trace one. Be that the 3D CAD for the housing or the PCB cad for the board.
If I'm going to make a or alter flashlight, the only reason I would do so is if there isn't one close to what I needed, and I'd make my own design because it's not complicated to start from scratch here.
But it would take you much more effort and probably cost you more (see the economies of scale argument).
Then again.. you sell (among other) small bars of metal with standard shoe mounts and tightening knobs for a pretty $60. http://shop.dm-accessories.com/products/uni-sab So I'm guessing that both reverse engineering and pricing wouldn't be an issue for you:)
Not sure if you meant to reply to me - but for what it's worth, I was pointing specifically to the fact that one of the two types takes reasonably standard batteries, albeit not AA, and the other (the actually programmable one, the HexBright Flex) will happily run off of one of those AA-based mobile phone chargers. Just don't expect it to run for very long because the 1.5V has to go through a boost first to get up to the USB voltage required (5V) and the battery's mAh rating decreases accordingly. But given the use case for "able to quickly replace with AA batteries when needed", that shouldn't be an issue.
Although Christian does say that this light may not be for everyone. For emergency lighting, I'd recommend a crank-type flashlight instead. Not as powerful, but certainly more appropriate.
Not really. Only the 'approvals' bit would cost a pretty penny.
All of the other measurements are routinely done at enthusiast forums, such as candlepowerforums or that polish one, with several members having reasonably expensive, calibrated, equipment to do just that. Their numbers are more reliable than that of the manufacturer's, too.
You can also usually find information on the LED used - in the case of the HexBright, a Cree XM-L - at those forums. The XM-L is still pretty new, though, so there haven't been any particular real world lifetime tests yet, but you can dig into the datasheet to see what Cree claims.
Which you could probably do with any flashlight if you know how to do that.
I don't know if you're serious - but I know plenty of people who can program but wouldn't know the first thing about electronics - and vice-versa.
Even if you do know enough about both, have you considered what you're saying?
First you have to take a reasonably powerful flashlight - say an older P7 because they're available cheap-ish - which still runs at about the same price as this thing.
Then you have to take it apart and make some space for a microcontroller and driving circuitry to do what you need it to do. You need to replace the standard button on it with a tristate button. Then you need to get a USB charging module in there. And then, once that's done, you still need to make it look nice and polished, fit appropriate batteries, and make it reasonably waterproof.
AND you still have to be within the original budget.
I'm sure it can be done. But then, you could probably build your own flashlight using a cardboard tube, an old broken coated spotlight bulb, some wires and some tape, and call the people who buy a standard flashlight at their local convenience store 'exploited'.
We are thinking about releasing the drawing for the body ("open source") so folks like you can design whatever accessories you want for it.
Note that he will be using stock components for some bits of the hardware. It's not up to him to 'open source' the microcontoller or Cree's LED solutions, for example. So in that manner of speaking, no, it's not 100% open source. Nor is a typical computer running Linux. But anybody can build a Linux-capable machine without knowing how to build a CPU and if you'd want, you can build your own HexBright without knowing how to build an LED.
I'm not really sure I like that idea. My uses for flashlights tend to be a) camping, and b) when the power goes out. Unfortunately with USB charging I would get one charge's worth of use in those situations.
With regular old batteries I can replace them to infinity, and if I forgot some I can pick them up at a gas station on my way to the woods.
See again above. Alternatively, note that there are two different HexBrights. The HexBright Prime uses CR123a batteries which convenience stores in the U.S. stock as far as I was able to tell (not so common in Europe). The 18650 used in the HexBright Flex is less common, but I would be surprised if there wouldn't be some manner of solution for that.
Keep in mind also that the design of the HexBright, as far as I know, is not set in stone just yet. So if you're saying "what if I want to power it directly from AA batteries?", get Christian's thoughts on that. He's been very responsive through the kickstarter project page.
give it a strobe function, a slow fade in function, an SOS function, set the levels of lighting the way you want them and not the manufacturer default of "off / barely bright enough to find my way around the house at night / ARGH MY EYES", etc.
Add further capabilities with RGB version down the line.
Also, I wouldn't be surprised if some of the data pins on the microcontroller go unused and if he's smart-ish, he'll break those out for you so you can hook up sensors.
Alternatively, perhaps you can work through the existing USB interface, though that requires more work on your part.
Why should people in any country have to subsidize a broken business model based on "artificial scarcity" in the 21st century? There are plenty of other ways research can be funded -- foundation, governments, private individuals, a basic income.
Did you read what you wrote? I only ask because of the following:
In the first sentence you say, essentially, that people shouldn't have to subsidize a broken business model. I don't see how the purchase of a product is considered a subsidy.
Then you go on to mention alternatives among which "governments". Wouldn't a government funding the research actually be a subsidy? Moreover, wouldn't that quite directly mean that even people who would never have purchased the product or made use of the services it enables would also be paying for it? In essence, you'd make every taxpayer 'subsidize' the research.
As for your other examples, in order of least viability: basic income: Say I make $150k a year by sitting on my ass thus leaving all my time available for the research. $10M / $150k/year ~= 67 years. I'm guessing I'll be dead long before then.
Private individuals and foundations (pretty much the same thing). If they are feeling a bit on the philanthropist side, then yes. Oddly enough, there aren't very many of those around and even those around limit their funding of research in a given time period. I.e. the Gates Foundation has plenty of cash to go around, and they still have plenty of cash to go around the next year. If they were 100% philanthropist, that cash wouldn't have been there the next year because it would already have been spent on the thousands of worthwhile research causes this year.
While it's nice to think that all things magically get paid for by essentially generous donations, it's not very realistic - and it won't be as long as there's a very real scarcity of a particular good: money. Until such a time that this is no longer true, there will be businesses funding research, and businesses will want to recoup that funding in one way or another, and thus be proponents of any system that helps them do so - including 'artificial scarcity'.
Well it's funny that you should mention the iPad - given that Apple will come down incredibly hard on anybody who were to manufacture an competing product that...
A. included Apple's connector design, so that the competing product can be used with one of hundreds (and growing) peripherals. B. included an operating system compatible with iOS, so that the competing product can make use of iOS application. C. looks too much like an iPad (see recent story re: Samsung).
In other words, the copy is not actually a copy. It may be a similar device.
To bring that concept back to my example.. if the competing company just saw the end-result of my research and said to themselves "let's see if we can do the same, start your research!" and came up with a rather different material or method to achieve the same, and still only spent a week on it and $100k, I wouldn't particularly think I'd have anything to complain about. That, after all, is in part how patents are actually supposed to work.
So when Sony installs software on your computer that enables them to remotely connect to it and issue commands as the administrator, that's good.
No, that would be quite horrible.
However, as far as I'm aware, the XCP software did not allow SONY or anybody else to remotely connect to the machine.
Just to make sure you understand me correctly: I'll state right here that what it did do is still highly undesirable and I do believe that those responsible should have been held accountable to the full extent of the law as it applies to several practices among which for the GPL violations.
I'll also state right here that I stated no opinions on the current LulzSec stuff. You can dig through my comment history to find one where I mentioned that the hacks were not some "largest public penetration test" but that the hacks were mostly for 'teh lulz'. I'd be honored if 'LulzSec' decided on that name based on that comment, but I highly doubt it;) ( For what it's worth, I do think it's bordering on the juvenile, and I'm not of the belief that SONY 'deserves' to be hacked any more than I believe anybody's insufficiently protected house deserves to be robbed. I also think, however, that SONY could both have prevented this and reacted more adequately, and certainly should lay the blame largely with themselves. )
Back to the beef of this thread, though... the assertion that it isn't a 'hack' and the secondary assertion that it isn't a 'rootkit'.
From that research (again as far as I can tell and I admit that it fits my memory so there may be some selective bias), it appears there were technically two behaviors: 1. It hid itself from the user and most of the system. 2. It 'phoned home', to look for updated album art.
With that in mind, I'll skip to your last question:
You also seem to have an interesting definition of 'rootkit'. Since I only know the real definition, could you kindly elaborate on yours?
Certainly. From the wikipedia article to which you linked:
A rootkit is software that 1. enables continued privileged access to a computer while 2. actively hiding its presence from administrators by subverting standard operating system functionality or other applications
I added the numbers there because they help me explain.
Part 2, "actively hiding its presence", is certainly in effect. No question there.
However, both parts 2 and 1 are required in order to fit the rootkit definition.
And while the software 'phones home' to check for new album art and subsequently doesn't do anything with it, it does not "enable continued privileged access to a computer".
But a new piece of hardware that is a generation more advanced might take competitors years to reverse engineer and gear up for fabrication
Imagine I spend the better part of 10 years and $50M to create a viable material to act as a lensing system for X-Rays, thus making it possible to create highly portable X-Ray machines and increasing x-ray resolution, by attempting thousands of different combinations of substrate elements, doping elements, etc.
You're saying that because a competitor can just buy such a machine, take a chunk of the material, toss that into their spectrometer/etc. to figure out what the material is, and replicate it within a week for $100K, my 'monopoly' - my chance to ever make back that $50M - should also be limited to that one week?
And knowing that this is the case, why would my potential customers buy a machine from me at a price that would allow me to recoup that $50M, when they can wait a week and get it from the competitor who only has to recoup $100K and can thus underprice me by a significant amount?
The whole "natural intellectual monopoly" idea is based on the assumption that something which is takes little resources (time/money/whatever) to reverse engineer must have taken little resources to engineer. An assumption that is increasingly incorrect.
There is a balance to be found between public interests and IP holders' interests, but this 'natural intellectual monopoly' does not provide said balance.
The really remarkable part, though, is that they're making any progress at all with HTML5, so some kudos is in order.
Not really all that remarkable. The main progress comes from the whole WhatWG efforts which in turn is basically the major browser makers saying "Screw you moving-like-molasses people and your incompatible XHTML 2.0, we'll just do things the way we agree to do them and everybody else can follow along or stay behind."
Same story here, except now it's not the major browser makers, but the major search engine companies - who want to be able to more easily index information. Why wait for what webmasters and users want, when your search engine(s) pretty much control the market and the webmaster really has little choice but to either follow along or stay behind?
This isn't necessarily a bad thing, as long as they all get along and the things introduced aren't wonderful in principle but a nightmare in practice (frames, anyone?)
Note that the system used is very much in line with HTML5 veering well away from the XHTML 2.0 changes, in that rather than introducing new elements that a browser or other parser could easily choke on, it introduces new properties which are easily ignored.
Did I miss something? Was somebody at SONY - presumably somebody high enough in the ranks to be referred to as 'SONY', and not some kid who got bored - actually connecting to your computer, exploiting a vulnerability, and using that to their advantage somehow?
I ask because that's what I'm thinking of when somebody says 'hack'.
I'm pretty sure that installing software when a CD is inserted, for the purposes of copyright protection, however failworthy and undesirable... is not hacking. Not even when you falsely apply the 'rootkit' label to that particular software and somehow by association will it into being a 'hack'.
To be fair, you can hardly expect Thunderbird to fix a bug in the underlying filesystem, can you?
Of course not - but it's not a bug (it's a shortcoming) and I do expect it to work with those shortcomings in a way to get around them.
You wouldn't say that a large program that compresses down to 2MB total simply cannot be distributed on a 3.5" 'floppy' because one can't expect the archiver/distribution platform to fix the 'bug' that is the 1.44MB limit of the medium. You'd expect it to split up the archive, and that's what people ended up doing (and to an extent, still do, but for different reasons).
One method to do this within the Windows ecosystem is to use GetVolumeInformation, get lpFileSystemFlags, and check if FILE_CASE_SENSITIVE_SEARCH is set.
If it is, the filesystem is case sensitive. If it isn't... it isn't.
Presume a renaming from "hello" to "HELLO".
In the case where the filesystem is case sensitive, all you have to do is check if the target filename exists. If it does, issue a warning. If it doesn't, just rename the file using existing code.
In the case where the filesystem is not case sensitive, I can't think of any reason why source "hello" and target "HELLO" (within the same directory) would be separate files, given that the filesystem itself doesn't allow for it. In this case, a rename routine can be called - be that an appropriate one or less appropriate one (e.g. renaming to a temp filename first).
Another solution - short of waiting for everybody to use case-sensitive filesystems - is to not rely solely on the filesystem for mail 'folder' names in the first place; albeit more human-friendly, it's what helps lead to these sorts of issues. Short of a E.g. when you download a file with a filename that already exists, browsers append " (N)" to the base filename, rather than complain the file already exists (unless you do a right-click + save (link) as). No reason TB couldn't employ a similar method for filenames that only differ in case - which would also make migration (in the sad event of having to migrate to a case-insensitive filesystem) easier as you don't have to manually resolve the conflicts.
There have been worse in the past - including loss of e-mail entirely - but nothing too recent.
But your statement requires knowledge of what you're comparing it to, to correctly interpret it.
Another bug, for example, is that at random it will simply stop displaying e-mails; either in the preview pane or when opened separately. A restart fixes this.
Another one involves the RSS reader functionality. If you select message A, the headers for message A are shown, and the body of message A begins to load. Now switch to message B. The headers for message B are shown, but as message A's body just then finishes loading, message A's body gets shown. For whatever reason, message B's body does not get shown. Deselect/reselect to fix.
Those are just ones I hit every day. The folder rename thing not quite as often, and renaming to a temp name and then to what you want isn't particularly damaging or in requirement of great effort.
However, the severity of a bug or how frequently it is encountered shouldn't be the only driving forces to fixing bugs. Triage is certainly a requirement, but every once in a while, any project would do well to take a day every quarter, say, and devote some developers to bugs that are just plain silly and pretty easy to fix. E.g. typos, a dialog layout with unnatural field ordering, a context menu with a divider bar as the last entry in the menu, etc. and, yes, renaming a folder to the same name with different case. It's not fixing critical flaws, people aren't going to upgrade just because those bugs are fixed, but they are polish and you can finally take them off your bug list, rather than marking new reports as duplicate each time one comes in.
I hope not... I wouldn't want to take away Wayne Lydecker's amusement before the bug's 10th Anniversary.
( The bug concerns renaming a folder from "Foo" to "foo" on a filesystem that does not differentiate between uppercase and lowercase, resulting in a "Foo already exists!" error, rather than the case change. )
Then what precisely did Google and Apple receive when they paid the licensing fee?
I don't know about Google, but seeing as Apple won't disclose the terms of the agreement - maybe they're not allowed to - we can only guess.
And as guesses go, this seems reasonable, albeit short-sighted by on the part of Google/Apple if it were so: Google/Apple acquired a license to use this technology themselves. I.e. if Google added it to their Google Maps app, that's fine. If Apple added it to some iTunes app, that's fine. It's their apps, they have a license to do so.
But if a third party starts using that technology, well that's not Google/Apple using it then, is it? That technology may be encapsulated in the same thing that Google and Apple's own apps might use (e.g. the API), but it's still the third party actually making use of it.
If third party use of the licensed tech is in fact not covered by the agreement, then what they received is something that's gonna hurt one way or another.
Because I cited the 2nd point as my main reason not to be too keen on GMO in general.
That said...
The rest doesn't really matter after that.
sure it does, because the argument was against GMOs wholesale, while there's nothing about a GMO that makes it automatically patented. There's absolutely no reason you couldn't go into a laboratory, genetically modify some vegetable for whatever purposes, and release that into the public domain rather than patenting it to hell and back.
Besides, as I also stated in my comment (another good reason not to 'stop right there'), non-GMO foods can be patented just as well.
No, the hosts file in itself, and editing thereof, is (or, well, can be) perfectly fine for the reasons you cited and many more. But it's also fine that malware scanners may opt to report anything they think looks suspicious. But you're about to address that, so.. on to that.
( Editing the quotes for formatting purposes )
"if changes are made to it that you are not aware of, would you really want a malware scanner to just ignore it?"
In my case? I actually COULD! How/Why??
Well, because I long ago designed a system (first in MS SQL, then in Borland Delphi, & lately in PyThon) that updates my HOSTS file with valid security data vs. bad sites (and my hardcoded favorites too) every 15 minutes from 15 reputable respected sites for that online...
But if you designed this system - or even if you didn't design it, but at least run it intentionally - doesn't that explicitly make you aware of the changes being made? You might not know the exact changes, but you know that there's a program running that could change the content of the hosts file every 15 minutes. My point was with regard to modifications that you're not aware of. Now, the hosts file handling, at least under Windows, is such that there's no explicit trail of what process wrote what to it, making it difficult to differentiate your program's changes from those of a piece of malware, so in your case you'd tell the malware scanner to just ignore the hosts file; at your own risk, but you clearly understand any risks involved there (given that your app helps to mitigate such risks).
Your next section is a bit disorderly, but as far as I can tell, you're saying that malware scanners could check the content of the hosts file to perform, for example, checks that a certain host actually meets the given IP address - and if that is the case, there is no problem, and it should ignore that entry.
But then you, quite correctly, point out that DNS server records might be incorrect. Or your DNS server settings were changed. Or a TCP/IP stack injection simply returns whatever the scanner wants to hear but when e.g. iexplore.exe (just to name a browser process) asks for it, servers up the malicious website.
So rather than just implicitly trust added IP/name combination on the basis that they appear to be correct at the time of the scan, it's better to alert the user that there's a value there that's not normally in it OR wasn't in there the last time the scan was run.
Note that the above is for on-demand scanners. Any 'active' scanner (the background running things) could just monitor process access to the file and then alert the user if some process is trying to write data to it, report the data, report the process, etc.
Now, you do make one more point:
MOST folks won't check into it (& many antivirus + antispyware and even HOSTS file population for security sites have checkers for this) to see if the site actually IS bad - they'll just "fry it".
The question is... is that a bad thing?
To simplify things a bit - perhaps oversimplify - there's 3 groups of people who would get hit by a warning regarding the hosts file having entries that aren't there originally / since the last scan.
Group 1: The people who did not edit the hosts file themselves nor installed a program - such as yours - that modifies the hosts file for them. In these cases, I'd argue that any removal of lines in the hosts file is less harmful than leaving them in, as the user clearly doesn't know why the entries are in there in the first place.
Group 2: The people who did not edit the hosts file themselves, but installed a program - such as yours - that modifies the hosts file for them. In these cases, although it may not be desirable for the modifications to be undone - it stands to reason that the program that made the modifications will redo the mo
The developers are different, the publisher is different, the prices, money value heck the economy is different. In europe the currency is different now. All in all, if you think about it it is still gamestops responsibility to honour them but they could argue that its too old or it was for a completely different game.
Wouldn't one then argue that if GameStop (presuming GameStop are who sold you the pre-order) felt that the product ultimately to be delivered (if at all) was so much different from the pre-ordered product, that they would void the pre-orders and return people's money?
Slashdot Mirror
But facebook can already do that - this isn't related to what facebook may or may not be doing behind the scenes.
Any third party with facial recognition software can also do this, but they'll need access to the people's profiles first.
And that's where a major change may be. Say you 'friend' a certain festival organizer because hey, if you friend them, you can keep updated on developments, or you get a discount, or whatever.
So you go to that festival, you have a good time, you also - unfortunately - get shitfaced.
The festival organizer takes pictures during the event, and posts them online.
Suddenly, you're not just some random guy in a festival picture that, albeit not impossible to find, requires a certain level of effort. No, now you're a tagged guy, and one needs but click through to get to your profile.
Now, yes.. you -chose- to friend the festival organizers., and by going to the festival you, implicitly or explicitly, agreed to photos of the festival to be used in publication, and so forth and so on.
The question is, did you knowingly and willingly also allow them to - automatically or otherwise - tag you in those photos?
The "knowingly" would certainly need scrutinizing, as the article seems to imply that facebook enabled by default and didn't particular let you know (I'm sure it can be found somewhere and you're supposed to check that every 10 minutes for whatever consent-who-needs-consent change they implemented this time) - and with it, the "willingly" part.
If you'd read the KickStarter page, you would've come across this part:
Which pretty much addresses half your post.
Your corrosion and wiring concerns are valid enough, but I'm confident that both will be treated appropriately. My only concern is actually with regard to the button (I'd like a button of the same type used on cameras so that a soft press can just turn it on for as long as I hold the button there, and a full button press actually switches) and aftermarket capabilities. The former being a use concern, the other being a versatility concern.
As for features not being 'the problem with flashlights', that depends on who you ask. I have a MagLite, it's just fine, and thanks to its bulk I can cave in somebody's skull with it - which makes it popular among guards and such. But it's still not going to be programmable, and it only has 3 modes (as mentioned above: off, not quite bright enough, and way too bright).
You do realize that you just searched for CR123 NiMH, right?
Would you like to retry that search with Lithium instead?
http://shop.ebay.com/i.html?_nkw=CR123a+lithium
Walmart obviously shows 1 hit on their site.. how many more do you need?
I've seen them aplenty in the U.S., they're typically on the racks near the registers.
They're a bit more rare in the EU, though. Plenty of websites that sell them, but step into a local Aldi or whatever and you may not have the luck of seeing them there.
Absolutely. But it's far more trivial to load a CAD file than to re-trace one. Be that the 3D CAD for the housing or the PCB cad for the board.
But it would take you much more effort and probably cost you more (see the economies of scale argument).
Then again.. you sell (among other) small bars of metal with standard shoe mounts and tightening knobs for a pretty $60. :)
http://shop.dm-accessories.com/products/uni-sab
So I'm guessing that both reverse engineering and pricing wouldn't be an issue for you
Not sure if you meant to reply to me - but for what it's worth, I was pointing specifically to the fact that one of the two types takes reasonably standard batteries, albeit not AA, and the other (the actually programmable one, the HexBright Flex) will happily run off of one of those AA-based mobile phone chargers. Just don't expect it to run for very long because the 1.5V has to go through a boost first to get up to the USB voltage required (5V) and the battery's mAh rating decreases accordingly. But given the use case for "able to quickly replace with AA batteries when needed", that shouldn't be an issue.
Although Christian does say that this light may not be for everyone. For emergency lighting, I'd recommend a crank-type flashlight instead. Not as powerful, but certainly more appropriate.
Not really. Only the 'approvals' bit would cost a pretty penny.
All of the other measurements are routinely done at enthusiast forums, such as candlepowerforums or that polish one, with several members having reasonably expensive, calibrated, equipment to do just that. Their numbers are more reliable than that of the manufacturer's, too.
You can also usually find information on the LED used - in the case of the HexBright, a Cree XM-L - at those forums. The XM-L is still pretty new, though, so there haven't been any particular real world lifetime tests yet, but you can dig into the datasheet to see what Cree claims.
I don't know if you're serious - but I know plenty of people who can program but wouldn't know the first thing about electronics - and vice-versa.
Even if you do know enough about both, have you considered what you're saying?
First you have to take a reasonably powerful flashlight - say an older P7 because they're available cheap-ish - which still runs at about the same price as this thing.
Then you have to take it apart and make some space for a microcontroller and driving circuitry to do what you need it to do.
You need to replace the standard button on it with a tristate button.
Then you need to get a USB charging module in there.
And then, once that's done, you still need to make it look nice and polished, fit appropriate batteries, and make it reasonably waterproof.
AND you still have to be within the original budget.
I'm sure it can be done. But then, you could probably build your own flashlight using a cardboard tube, an old broken coated spotlight bulb, some wires and some tape, and call the people who buy a standard flashlight at their local convenience store 'exploited'.
From one of Christian's comments:
Also, in response to the following question:
He answered:
So, yes, it does appear that he's planning on making it 100% open source.
From one of Christian's comments:
Note that he will be using stock components for some bits of the hardware. It's not up to him to 'open source' the microcontoller or Cree's LED solutions, for example. So in that manner of speaking, no, it's not 100% open source. Nor is a typical computer running Linux. But anybody can build a Linux-capable machine without knowing how to build a CPU and if you'd want, you can build your own HexBright without knowing how to build an LED.
http://www.google.com/search?q=mobile+phone+charger+aa
See again above. Alternatively, note that there are two different HexBrights. The HexBright Prime uses CR123a batteries which convenience stores in the U.S. stock as far as I was able to tell (not so common in Europe).
The 18650 used in the HexBright Flex is less common, but I would be surprised if there wouldn't be some manner of solution for that.
Keep in mind also that the design of the HexBright, as far as I know, is not set in stone just yet. So if you're saying "what if I want to power it directly from AA batteries?", get Christian's thoughts on that. He's been very responsive through the kickstarter project page.
Program it to do whatever you want?
give it a strobe function, a slow fade in function, an SOS function, set the levels of lighting the way you want them and not the manufacturer default of "off / barely bright enough to find my way around the house at night / ARGH MY EYES", etc.
Add further capabilities with RGB version down the line.
Also, I wouldn't be surprised if some of the data pins on the microcontroller go unused and if he's smart-ish, he'll break those out for you so you can hook up sensors.
Alternatively, perhaps you can work through the existing USB interface, though that requires more work on your part.
Did you read what you wrote? I only ask because of the following:
In the first sentence you say, essentially, that people shouldn't have to subsidize a broken business model.
I don't see how the purchase of a product is considered a subsidy.
Then you go on to mention alternatives among which "governments". Wouldn't a government funding the research actually be a subsidy? Moreover, wouldn't that quite directly mean that even people who would never have purchased the product or made use of the services it enables would also be paying for it? In essence, you'd make every taxpayer 'subsidize' the research.
As for your other examples, in order of least viability:
basic income: Say I make $150k a year by sitting on my ass thus leaving all my time available for the research. $10M / $150k/year ~= 67 years. I'm guessing I'll be dead long before then.
Private individuals and foundations (pretty much the same thing). If they are feeling a bit on the philanthropist side, then yes. Oddly enough, there aren't very many of those around and even those around limit their funding of research in a given time period. I.e. the Gates Foundation has plenty of cash to go around, and they still have plenty of cash to go around the next year. If they were 100% philanthropist, that cash wouldn't have been there the next year because it would already have been spent on the thousands of worthwhile research causes this year.
While it's nice to think that all things magically get paid for by essentially generous donations, it's not very realistic - and it won't be as long as there's a very real scarcity of a particular good: money.
Until such a time that this is no longer true, there will be businesses funding research, and businesses will want to recoup that funding in one way or another, and thus be proponents of any system that helps them do so - including 'artificial scarcity'.
Well it's funny that you should mention the iPad - given that Apple will come down incredibly hard on anybody who were to manufacture an competing product that...
A. included Apple's connector design, so that the competing product can be used with one of hundreds (and growing) peripherals.
B. included an operating system compatible with iOS, so that the competing product can make use of iOS application.
C. looks too much like an iPad (see recent story re: Samsung).
In other words, the copy is not actually a copy. It may be a similar device.
To bring that concept back to my example.. if the competing company just saw the end-result of my research and said to themselves "let's see if we can do the same, start your research!" and came up with a rather different material or method to achieve the same, and still only spent a week on it and $100k, I wouldn't particularly think I'd have anything to complain about. That, after all, is in part how patents are actually supposed to work.
No, that would be quite horrible.
However, as far as I'm aware, the XCP software did not allow SONY or anybody else to remotely connect to the machine.
Just to make sure you understand me correctly:
I'll state right here that what it did do is still highly undesirable and I do believe that those responsible should have been held accountable to the full extent of the law as it applies to several practices among which for the GPL violations.
I'll also state right here that I stated no opinions on the current LulzSec stuff. You can dig through my comment history to find one where I mentioned that the hacks were not some "largest public penetration test" but that the hacks were mostly for 'teh lulz'. I'd be honored if 'LulzSec' decided on that name based on that comment, but I highly doubt it ;)
( For what it's worth, I do think it's bordering on the juvenile, and I'm not of the belief that SONY 'deserves' to be hacked any more than I believe anybody's insufficiently protected house deserves to be robbed. I also think, however, that SONY could both have prevented this and reacted more adequately, and certainly should lay the blame largely with themselves. )
Back to the beef of this thread, though... the assertion that it isn't a 'hack' and the secondary assertion that it isn't a 'rootkit'.
My memory on this is rusty, however, and wikipedia of course only provides a summary (summary: it's a rootkit!) and cites a source which you then have to follow up several chains and finding the correct locations to some broken links to find any actual information at e.g. Mark Russinovich's research.
http://blogs.technet.com/b/markrussinovich/archive/2005/10/31/sony-rootkits-and-digital-rights-management-gone-too-far.aspx
http://blogs.technet.com/b/markrussinovich/archive/2005/11/04/more-on-sony-dangerous-decloaking-patch-eulas-and-phoning-home.aspx
From that research (again as far as I can tell and I admit that it fits my memory so there may be some selective bias), it appears there were technically two behaviors:
1. It hid itself from the user and most of the system.
2. It 'phoned home', to look for updated album art.
With that in mind, I'll skip to your last question:
Certainly. From the wikipedia article to which you linked:
I added the numbers there because they help me explain.
Part 2, "actively hiding its presence", is certainly in effect. No question there.
However, both parts 2 and 1 are required in order to fit the rootkit definition.
And while the software 'phones home' to check for new album art and subsequently doesn't do anything with it, it does not "enable continued privileged access to a computer".
As such, it's not a rootkit.
Now, mind you, the subsequently released removal tool had a serious flaw in it that could indeed lead to privileged access.
http://freedom-to-tinker.com/blog/felten/sonys-web-based-uninstaller-opens-big-security-hole-sony-recall-discs
This,
Imagine I spend the better part of 10 years and $50M to create a viable material to act as a lensing system for X-Rays, thus making it possible to create highly portable X-Ray machines and increasing x-ray resolution, by attempting thousands of different combinations of substrate elements, doping elements, etc.
You're saying that because a competitor can just buy such a machine, take a chunk of the material, toss that into their spectrometer/etc. to figure out what the material is, and replicate it within a week for $100K, my 'monopoly' - my chance to ever make back that $50M - should also be limited to that one week?
And knowing that this is the case, why would my potential customers buy a machine from me at a price that would allow me to recoup that $50M, when they can wait a week and get it from the competitor who only has to recoup $100K and can thus underprice me by a significant amount?
The whole "natural intellectual monopoly" idea is based on the assumption that something which is takes little resources (time/money/whatever) to reverse engineer must have taken little resources to engineer. An assumption that is increasingly incorrect.
There is a balance to be found between public interests and IP holders' interests, but this 'natural intellectual monopoly' does not provide said balance.
Not really all that remarkable. The main progress comes from the whole WhatWG efforts which in turn is basically the major browser makers saying "Screw you moving-like-molasses people and your incompatible XHTML 2.0, we'll just do things the way we agree to do them and everybody else can follow along or stay behind."
Same story here, except now it's not the major browser makers, but the major search engine companies - who want to be able to more easily index information. Why wait for what webmasters and users want, when your search engine(s) pretty much control the market and the webmaster really has little choice but to either follow along or stay behind?
This isn't necessarily a bad thing, as long as they all get along and the things introduced aren't wonderful in principle but a nightmare in practice (frames, anyone?)
Note that the system used is very much in line with HTML5 veering well away from the XHTML 2.0 changes, in that rather than introducing new elements that a browser or other parser could easily choke on, it introduces new properties which are easily ignored.
Wait.. when did SONY hack your system?
Did I miss something? Was somebody at SONY - presumably somebody high enough in the ranks to be referred to as 'SONY', and not some kid who got bored - actually connecting to your computer, exploiting a vulnerability, and using that to their advantage somehow?
I ask because that's what I'm thinking of when somebody says 'hack'.
I'm pretty sure that installing software when a CD is inserted, for the purposes of copyright protection, however failworthy and undesirable... is not hacking. Not even when you falsely apply the 'rootkit' label to that particular software and somehow by association will it into being a 'hack'.
Of course not - but it's not a bug (it's a shortcoming) and I do expect it to work with those shortcomings in a way to get around them.
You wouldn't say that a large program that compresses down to 2MB total simply cannot be distributed on a 3.5" 'floppy' because one can't expect the archiver/distribution platform to fix the 'bug' that is the 1.44MB limit of the medium. You'd expect it to split up the archive, and that's what people ended up doing (and to an extent, still do, but for different reasons).
One method to do this within the Windows ecosystem is to use GetVolumeInformation, get lpFileSystemFlags, and check if FILE_CASE_SENSITIVE_SEARCH is set.
If it is, the filesystem is case sensitive. If it isn't... it isn't.
Presume a renaming from "hello" to "HELLO".
In the case where the filesystem is case sensitive, all you have to do is check if the target filename exists. If it does, issue a warning. If it doesn't, just rename the file using existing code.
In the case where the filesystem is not case sensitive, I can't think of any reason why source "hello" and target "HELLO" (within the same directory) would be separate files, given that the filesystem itself doesn't allow for it. In this case, a rename routine can be called - be that an appropriate one or less appropriate one (e.g. renaming to a temp filename first).
Another solution - short of waiting for everybody to use case-sensitive filesystems - is to not rely solely on the filesystem for mail 'folder' names in the first place; albeit more human-friendly, it's what helps lead to these sorts of issues. Short of a
E.g. when you download a file with a filename that already exists, browsers append " (N)" to the base filename, rather than complain the file already exists (unless you do a right-click + save (link) as).
No reason TB couldn't employ a similar method for filenames that only differ in case - which would also make migration (in the sad event of having to migrate to a case-insensitive filesystem) easier as you don't have to manually resolve the conflicts.
There have been worse in the past - including loss of e-mail entirely - but nothing too recent.
But your statement requires knowledge of what you're comparing it to, to correctly interpret it.
Another bug, for example, is that at random it will simply stop displaying e-mails; either in the preview pane or when opened separately. A restart fixes this.
Another one involves the RSS reader functionality. If you select message A, the headers for message A are shown, and the body of message A begins to load. Now switch to message B. The headers for message B are shown, but as message A's body just then finishes loading, message A's body gets shown. For whatever reason, message B's body does not get shown.
Deselect/reselect to fix.
Those are just ones I hit every day. The folder rename thing not quite as often, and renaming to a temp name and then to what you want isn't particularly damaging or in requirement of great effort.
However, the severity of a bug or how frequently it is encountered shouldn't be the only driving forces to fixing bugs. Triage is certainly a requirement, but every once in a while, any project would do well to take a day every quarter, say, and devote some developers to bugs that are just plain silly and pretty easy to fix. E.g. typos, a dialog layout with unnatural field ordering, a context menu with a divider bar as the last entry in the menu, etc. and, yes, renaming a folder to the same name with different case. It's not fixing critical flaws, people aren't going to upgrade just because those bugs are fixed, but they are polish and you can finally take them off your bug list, rather than marking new reports as duplicate each time one comes in.
You're now referring to the filter, though. That's the quickfilter that's above the messages list.
Search, on the other hand, most certainly can.
"Status" "isn't" "Starred"
While not as convenient as the filter, it'll probably get done what you need done with the stars?
Though I hid the 'starred' column as I don't even know what its use is next to Tags (I've got saved searches for the tags I use frequently).
https://bugzilla.mozilla.org/show_bug.cgi?id=92165
I hope not... I wouldn't want to take away Wayne Lydecker's amusement before the bug's 10th Anniversary.
( The bug concerns renaming a folder from "Foo" to "foo" on a filesystem that does not differentiate between uppercase and lowercase, resulting in a "Foo already exists!" error, rather than the case change. )
I don't know about Google, but seeing as Apple won't disclose the terms of the agreement - maybe they're not allowed to - we can only guess.
And as guesses go, this seems reasonable, albeit short-sighted by on the part of Google/Apple if it were so:
Google/Apple acquired a license to use this technology themselves. I.e. if Google added it to their Google Maps app, that's fine. If Apple added it to some iTunes app, that's fine. It's their apps, they have a license to do so.
But if a third party starts using that technology, well that's not Google/Apple using it then, is it? That technology may be encapsulated in the same thing that Google and Apple's own apps might use (e.g. the API), but it's still the third party actually making use of it.
If third party use of the licensed tech is in fact not covered by the agreement, then what they received is something that's gonna hurt one way or another.
I don't wanna. Know why?
Because I cited the 2nd point as my main reason not to be too keen on GMO in general.
That said...
sure it does, because the argument was against GMOs wholesale, while there's nothing about a GMO that makes it automatically patented. There's absolutely no reason you couldn't go into a laboratory, genetically modify some vegetable for whatever purposes, and release that into the public domain rather than patenting it to hell and back.
Besides, as I also stated in my comment (another good reason not to 'stop right there'), non-GMO foods can be patented just as well.
Ah - just a case of mistaken intention, then :)
No, the hosts file in itself, and editing thereof, is (or, well, can be) perfectly fine for the reasons you cited and many more. But it's also fine that malware scanners may opt to report anything they think looks suspicious. But you're about to address that, so.. on to that.
( Editing the quotes for formatting purposes )
But if you designed this system - or even if you didn't design it, but at least run it intentionally - doesn't that explicitly make you aware of the changes being made? You might not know the exact changes, but you know that there's a program running that could change the content of the hosts file every 15 minutes.
My point was with regard to modifications that you're not aware of.
Now, the hosts file handling, at least under Windows, is such that there's no explicit trail of what process wrote what to it, making it difficult to differentiate your program's changes from those of a piece of malware, so in your case you'd tell the malware scanner to just ignore the hosts file; at your own risk, but you clearly understand any risks involved there (given that your app helps to mitigate such risks).
Your next section is a bit disorderly, but as far as I can tell, you're saying that malware scanners could check the content of the hosts file to perform, for example, checks that a certain host actually meets the given IP address - and if that is the case, there is no problem, and it should ignore that entry.
But then you, quite correctly, point out that DNS server records might be incorrect. Or your DNS server settings were changed. Or a TCP/IP stack injection simply returns whatever the scanner wants to hear but when e.g. iexplore.exe (just to name a browser process) asks for it, servers up the malicious website.
So rather than just implicitly trust added IP/name combination on the basis that they appear to be correct at the time of the scan, it's better to alert the user that there's a value there that's not normally in it OR wasn't in there the last time the scan was run.
Note that the above is for on-demand scanners. Any 'active' scanner (the background running things) could just monitor process access to the file and then alert the user if some process is trying to write data to it, report the data, report the process, etc.
Now, you do make one more point:
The question is... is that a bad thing?
To simplify things a bit - perhaps oversimplify - there's 3 groups of people who would get hit by a warning regarding the hosts file having entries that aren't there originally / since the last scan.
Group 1: The people who did not edit the hosts file themselves nor installed a program - such as yours - that modifies the hosts file for them.
In these cases, I'd argue that any removal of lines in the hosts file is less harmful than leaving them in, as the user clearly doesn't know why the entries are in there in the first place.
Group 2: The people who did not edit the hosts file themselves, but installed a program - such as yours - that modifies the hosts file for them.
In these cases, although it may not be desirable for the modifications to be undone - it stands to reason that the program that made the modifications will redo the mo
Wouldn't one then argue that if GameStop (presuming GameStop are who sold you the pre-order) felt that the product ultimately to be delivered (if at all) was so much different from the pre-ordered product, that they would void the pre-orders and return people's money?