Luxury, yes, but I'm not actually sure about the margins. They make money on every car sold, but they still end up in the red most quarters due to things like R&D costs. Now, maybe they just spend a ton on R&D (and probably also things like Supercharger stations, the new factory, etc.), but they aren't exactly raking in the dough the way "high margin" implies.
Recalls are usually checked at routine maintenance time, too. My Subaru (I'd love a Tesla, but they don't suit my driving needs) got a couple of minor repairs - nothing likely to be life-threatening, just stuff that would probably cost them more to repair if they ignored it - for free when I took it in for its scheduled maintenance.
Now, Teslas don't need a lot of servicing, but they do get some. I'm sure some people will schedule a special service time to have the seatbelt checked, but for most people they'll probably just give the belt a good tug / look at and poke the bolt, conclude that it's fine, and forget about it until the next time they take their car in for routine maintenance. At that time, the tech will spend the extra few minutes - highly unlikely to average anywhere near half an hour - to check it themselves.
Still, good on Tesla for doing this. Remember that, for people who bring in their car *just* for this recall, there's a lot of overhead and it ends up costing much more than just the tech's time. Still probably not a major amount, even if a lot of people do participate in the recall outside their scheduled maintenance cycle, but non-trivial.
Emulators are run-time, this is compile-time. The closest thing I'm aware of it WineLib, which lets people compile Win32 code for Linux or OS X, and takes care of stuff like translating DirectX calls to OpenGL ones. It's reasonably "successful" in terms of usage, but far from complete or bug-free. A lot of apps just won't work through it, and many others will exhibit new and exciting bugs.
Not to contradict your point in any way, but Uber has been available on Windows Phone for months, possibly years. Lyft is not, though. It's a WP8 app, but will run fine on W10M.
Whoops, thanks, you're right. Three options for what the machine does when the configuration changes, including do nothing, switch automatically, or prompt. That's even better than needing to set it beforehand or trusting Microsoft to get it right. I primarily run Win10 on a desktop, so I hadn't seen the prompt.
I take it you not only haven't used, but haven't even *seen* Win10?
If your computer has an attached keyboard and you don't go well out of your way to do so, you will never see "Metro" in Win10. No full-screen Start, everything runs in a window, no Charms bar, no App Bar, etc. Windows Store apps (including the Store itself) now run in windows on the desktop. Title bars are visible at all times and can be dragged, edges can be dragged to resize, apps can be snapped with desktop apps, and so on.
Now, if your computer is a tablet without an attached keyboard, then yes, the OS will default to "tablet mode" with the full-screen apps and so on. You can tell it not to do so, though; it's a simple setting (Settings -> System -> Tablet Mode). You can change the current mode, the default mode, and whether it automatically switches depending on the hardware configuration.
The sad thing is, the Surface RT (and Windows RT generally) would have had a chance if MS has just not crippled the thing with insane lockdowns. It had the full Win32 and.NET 4.x APIs, used standard driver models so you could easily add support for devices that used its full-size USB port, and supported a bunch of features found in no other mainstream ARM tablet (full file system access, built-in script engines, multi-user capability, Windows networking, placing any windows you wanted to side-by-side, booting off removable media, browser with developer tools, etc.). It had compelling hardware, aside from the lowish screen resolution (and it's not *that* low, the MacBook Air has the same resolution, but cost a hell of a lot more).
It was trivially easy to port many Win32 programs to it; if they would compile in Visual Studio 2012, you could compile them for RT..NET programs didn't even need re-compiling. Drivers built using the modern driver kits were as easy to port as Win32 programs; some open-source drivers were successfully ported, and Pluggable even managed to get theirs USB Ethernet dongle's driver signed by MS before MS backpedaled on that. The bitch was getting past the stupid signature checks (most people were even less lucky than Pluggable). You could compile (where needed), and you could copy the programs to the tablet. You could even tell it to run them as Admin. But, without a jailbreak or a Microsoft signature (not just any Authenticode signature, it had to be from specific Microsoft keys), it wouldn't run.
That doomed the whole RT ecosystem. The app store's offerings were neither plentiful enough nor desirable enough to make the tablet worth its price (which was good for an 8-hour-battery laptop, but high for an ARM tablet). The initial jailbreak brought a surge of interest in porting open-source programs, and even led to the development of an x86-to-ARM dynamic recompilation (like emulation, but faster) layer that allowed running unmodified Win32 programs, including some old games. For months, MS didn't bother people who were finally getting to use their tablets as actually computers... and then 8.1 came out, and they blocked the jailbreak four different ways. There's a new jailbreak out now, but people just don't care much anymore. I don't know what idiot at MS thought that making RT even less useful was going to increase sales, but they traded in their.22 pocket footgun for a.50 fully automatic footrifle, and people just stopped bothering with it.
KOTOR (Knights Of The Old Republic) is different from "Star Wars: The Old Republic"; the latter is an MMO, currently supported, and more akin to WOW than to KOTOR except in its story aesthetic.
* Only if you don't include the weight and battery life among those specs. As a computer, it's overpriced. As a *portable* computer, it's just about smack in the middle of the pack for its class, price-wise.
* Switch the touch keyboard to the "Standard" or full layout. It has the meta keys you are looking for. You may need to enable it. In Win10, the setting is at Settings -> Devices -> Typing -> "Add the standard keyboard layout as a touch keyboard option".
* In desktop apps (i.e. non-Store apps), tap-and-hold is always right-click. In Win8.x Windows Store apps, right-clicking brings up the app bar; you can also achieve this by swiping in to the screen from above or below.
* I generally avoid the app store stuff - for me, its limitations aren't worth it, even in a touch environment, and that's without even getting into the fact that it's a DRM system.
For a "fundamentally broken" browser, it's very good at rendering web pages, has nicely configurable settings, is quite stable, and very fast. Do you have an actual objection to any aspect of it, or are you just talking out your ass? You don't even present a subjective, much less objective, fault in the browser. I could mention a few, but eh, none count as anything like "fundamentally broken".
Midori (http://midori-browser.org/) is pretty good for a fairly thin wrapper around WebKit. It's lacking a bunch of features, of course, but it has a tiny install and RAM footprint relative to mainstream browsers.
It's an OS commend injection vulnerability. Deserializing an object should not, by itself, ever execute arbitrary code. The only function that automatically runs on a deserialized object is that object's readObject function, which should in no way be usable to execute an arbitrary OS command. Apparently the writers of this library would find that concept bemusing.
This isn't a matter of
Deserialize the object, see if it's an instance of FootGun, and if so call its shoot() function. We're just that stupid.
This is more a matter of
Well, we expect an object of type Foo, but it should matter what it is as long as we don't call any functions on it and it can only be something in our server's classpath anyhow. Let's deserialize it to see what it is. Huh, it deserialized to a FootGun instead, and for some reason the FootGun class automatically calls shoot() upon deserialization!
Why the fuck do we even have a self-firing FootGun in our classpath, anyhow?
In case you missed it, the Apache Commons Collection library is, for some reason, shipping a self-firing footgun. They should patch that.
Apache Commons Collections contains an arbitrary shell command injection vulnerability reachable from the readObject function of one of its Serializable classes. Due to the way Java deserialization works, any Serializable class can be specified in a serialized Java object format, and unless there's code filtering the serialized binary data before deserializing it, that's enough to trigger the exploit.
Saying "Do not deserialize objects with executable code from the internet." sounds like a solution, but Java deserialization of objects passed on the wire is everywhere, and often even used pre-auth. Some of these things are management interfaces that definitely shouldn't be exposed to the Internet, but most of them will be exposed to the local network and that's still bad (arbitrary code execution in a server's management interface, callable by anybody who has access to the internal network even if they have no creds).
Fixing Commons Collection so that it can't be used for shell command injection would be a much more proper fix. Deserializing Java objects from the Internet *shouldn't* be dangerous; the simple act of deserializing an object should never inherently by harmful! Remember, the attacker can't force you to call any method of those objects. The attacker can't send objects that you don't already have class definitions for. The attacker can't add functions, or otherwise modify the class definitions. The only thing the attacker can be sure will happen is that the readObjection method - if it exists for the class in question - will execute. That's it. That should *NEVER* be enough to get arbitrary code execution!
They do, actually, at my local airport. It's something like $8 for domestic and $13 to Canada, but you can send home that little whatever that you forgot.
For the body scanner, put it on your sides. The plane of the scanner field only rotates across your front and back; it will miss anything directly on your sides. Wear slightly loose clothes and you can strap a weapon (or other object) a number of places outside the areas that the scanner "sees". Upper arms near your elbows (well out to the sides in "scanner pose"), sides of your torso unless you're super skinny, outsides of your legs if it doesn't show through your pants, insides of your legs (especially near the ankle) if you keep your feet a little wider than you should, etc.
For the baggage X-ray, just put "safe" stuff around the prohibited item. Tablet computers are great here; for some reason they're considered safe despite usually having plenty of metals, including potentially-dangerous lithium, in their chassis. Laptop power bricks and external hard drives are pretty hard to scan through; I've seen what they look like on the screens. Small items like pens, mint tins, coins, keys, flashdrives, jewelry, and so on can clutter the X-ray image and conceal stuff behind them, directly or by simply breaking up the outline sufficiently. A bag of toiletries containing a bunch of sub-3-oz tubes of this and that is *supposed* to be run through separately, but I've never once had a problem leaving it in my bag and I fly over a dozen times a year.
It's embarrassingly easy to get shit past those morons. Sometimes I do it by accident, like forgetting a pocketknife or bottle of soda. If it's not on the outer part of the bag, they usually miss it.
The TSA confiscates hundreds - over a thousand last year - of guns from law-abiding citizens (disproportionately Texans) who go armed so frequently, as a matter of habit analogous to wearing a watch of carrying a phone, that they forget to remove their weapons before going to the airport. I fully believe the vast majority of those are accidental. The amazing thing is that the TSA actually manages to find that many; I've certainly accidentally passed prohibited items (not firearms or munitions, but knives, liquids, and so on) through the scanners, and am not that surprised the GP could have gotten a box of ammo through without even trying to conceal it.
It's less about preventing fingerprinting and more about preventing third-party requests. For example, browsing Slashdot with Slashdot's ads ostensibly disabled, there are still eight different third-party requests (not counting stuff I've whitelisted, like jquery and other necessary evils) that my browser has blocked. That's not counting requests that the responses to those blocked requests themselves would have generated, which is usually several times as many (page loads third-party scripts A, B, and C, each of them loads another script and a tracking pixel, so you go from three blocked requests to nine third-party requests if you don't filter).
Not that I'm aware of. The closest is, oddly, IE; it has "tab grouping" that color-codes tabs so you can tell which tabs were opened from which other tabs. Still only along the top, though, and it doesn't actually show the hierarchy.
I'd really like to have tab trees in Pale Moon. At least Pale Moon supports switching tabs (Ctrl+Tab shortcut) in recently-used order... Firefox's default tab handling is shit (and not just for the location or lack of hierarchy).
Really, Mozilla? Copy a feature IE has had for years, ok, fine, good for you, have a cookie.
Make it completely obscure how to use it in the common scenario (i.e. not launching in Private Browsing mode), though? That's just... Stupid. Ridiculously stupid.
Fortunately for the world, but unfortunately for you, pretty much everybody is moving away from Flash. I block Flash by default. Three years ago I was asked to enable it for a site a few times a day, with an ugly grey box if I didn't. Now I don't remember needing to do so any time in the last few months, and I rarely even see the block indicator light up.
The funny thing is, this "tracking protection" feature is lifted wholesale from IE, which has had it since v9 (with a less-user-friendly version present in v8). The only difference is that, in IE, tracking protection is off by default but can be turned on (temporarily or as the new default) easily, whether in Private Browsing mode or not. In Firefox, so far as I can tell from the high-propaganda-low-content links in the TFS, it's only active in Private Browsing mode but at least it's active by default there. That's... progress, sure, but also somewhat misses the point.
I mean, most people on Firefox who care about privacy probably already figured out how to get Ghostery, Privacy Badger, AdBlock*, NoScript, and/or some other combination of helpful extensions installed. But still, there's something very funny about Mozilla coming up with a "block requests to third-party content to preserve privacy!" feature like it's 2011 (or 2009, but being very slightly less pussyfooted about it than MS was; in IE8 you had to enable the feature for each browser session and couldn't make it turn on by default). Making it active by default in Private Browsing mode is a good move, but scarcely an *impressive* one...
So, if the replication in different labs, by different teams, using different test apparatus, doesn't constitute replication... what does?
As I said above, you're full of shit. You know what's less scientific than not publishing a theory? Sticking your hands over your ears and shouting really loudly that something isn't real, no matter how many times it's demonstrated.
You're an idiot, with no better understanding of science than a young-earth creationist.
NOT counting the inventors, it's been duplicated in four separate experiments at two different labs: China's Northwestern Polytechnical University in 2010, NASA's Advanced Propulsion Physics Lab (Eagleworks) in 2014 and twice in 2015 (the latter of which is the test being reported here).
Also, it's pretty clear you don't understand how scientific publication works. For that matter, you seem unclear on the entire concept of "science" itself. Publication is not, and can never by, science. Science is in the creation, testing, and refining or rejecting of theories. Publication is merely the process of distributing the result of science.
The problem is, nobody yet has a testable theory for how the drive works. They can (and have, repeatedly and replication) test *that* it works, but "I don't know why" is not a valid scientific explanation for an observed phenomenon, and will be rejected if anybody tries to publish "new space drive discovered" in a peer-reviewed journal. The theoretical explanation doesn't always come before the experimental results. However, the experimental results - not to be confused with the drive theory - can be and have been published.
Not having a scientific theory for an observed phenomenon doesn't make the phenomenon go away. It doesn't even make the phenomenon un-scientific. Not does it make measurements of the phenomenon unscientific.
Peer-reviewed publication of a tested theory is the end goal of science, but that doesn't make stuff which hasn't yet been published in a peer-reviewed journal "not science" any more than a person who hasn't yet returned home could be said to "not be vacationing".
You're confusing the EM Drive with a photon drive. The EM Drive requires a sealed resonant cavity. A photon drive requires an open-ended reflective emitter. Photon drives are, essentially, standard reaction drives that derive their thrust from the photons being shot out the back of the drive. The EM Drive - assuming it really works - is something else entirely, because there's nowhere for the photons to go; the net thrust they impart on the chamber seems like it ought to be zero.
As a side note, experimental results indicate that the EM Drive is about 400x the efficiency of a photon drive (1.3 microN / W for the EM Drive vs. 3.3 nanoN / W). This is one of the reasons (the other being that sealed cavity thing) that it's clearly *not* a photon drive in any sense we are familiar with.
The efficiency of photon drives is known very precisely, and can be taken into account with spacecraft... if such infinitesimal thrusts are even relevant. For satellites, the thrust generated by their antennas - which usually aren't even perfectly directional, and thus partially counteract themselves by sending some of the photons the wrong way - is probably lost in the noise of other trivial influences on their orbits.
Slashdot Mirror
Luxury, yes, but I'm not actually sure about the margins. They make money on every car sold, but they still end up in the red most quarters due to things like R&D costs. Now, maybe they just spend a ton on R&D (and probably also things like Supercharger stations, the new factory, etc.), but they aren't exactly raking in the dough the way "high margin" implies.
Recalls are usually checked at routine maintenance time, too. My Subaru (I'd love a Tesla, but they don't suit my driving needs) got a couple of minor repairs - nothing likely to be life-threatening, just stuff that would probably cost them more to repair if they ignored it - for free when I took it in for its scheduled maintenance.
Now, Teslas don't need a lot of servicing, but they do get some. I'm sure some people will schedule a special service time to have the seatbelt checked, but for most people they'll probably just give the belt a good tug / look at and poke the bolt, conclude that it's fine, and forget about it until the next time they take their car in for routine maintenance. At that time, the tech will spend the extra few minutes - highly unlikely to average anywhere near half an hour - to check it themselves.
Still, good on Tesla for doing this. Remember that, for people who bring in their car *just* for this recall, there's a lot of overhead and it ends up costing much more than just the tech's time. Still probably not a major amount, even if a lot of people do participate in the recall outside their scheduled maintenance cycle, but non-trivial.
Emulators are run-time, this is compile-time. The closest thing I'm aware of it WineLib, which lets people compile Win32 code for Linux or OS X, and takes care of stuff like translating DirectX calls to OpenGL ones. It's reasonably "successful" in terms of usage, but far from complete or bug-free. A lot of apps just won't work through it, and many others will exhibit new and exciting bugs.
Loosing... an arrow? Loosing the dogs of war? "Loosing" as in releasing, a reference to the way Windows 10 Mobile is being released imminently?
Not to contradict your point in any way, but Uber has been available on Windows Phone for months, possibly years. Lyft is not, though. It's a WP8 app, but will run fine on W10M.
Whoops, thanks, you're right. Three options for what the machine does when the configuration changes, including do nothing, switch automatically, or prompt. That's even better than needing to set it beforehand or trusting Microsoft to get it right. I primarily run Win10 on a desktop, so I hadn't seen the prompt.
I take it you not only haven't used, but haven't even *seen* Win10?
If your computer has an attached keyboard and you don't go well out of your way to do so, you will never see "Metro" in Win10. No full-screen Start, everything runs in a window, no Charms bar, no App Bar, etc. Windows Store apps (including the Store itself) now run in windows on the desktop. Title bars are visible at all times and can be dragged, edges can be dragged to resize, apps can be snapped with desktop apps, and so on.
Now, if your computer is a tablet without an attached keyboard, then yes, the OS will default to "tablet mode" with the full-screen apps and so on. You can tell it not to do so, though; it's a simple setting (Settings -> System -> Tablet Mode). You can change the current mode, the default mode, and whether it automatically switches depending on the hardware configuration.
The sad thing is, the Surface RT (and Windows RT generally) would have had a chance if MS has just not crippled the thing with insane lockdowns. It had the full Win32 and .NET 4.x APIs, used standard driver models so you could easily add support for devices that used its full-size USB port, and supported a bunch of features found in no other mainstream ARM tablet (full file system access, built-in script engines, multi-user capability, Windows networking, placing any windows you wanted to side-by-side, booting off removable media, browser with developer tools, etc.). It had compelling hardware, aside from the lowish screen resolution (and it's not *that* low, the MacBook Air has the same resolution, but cost a hell of a lot more).
It was trivially easy to port many Win32 programs to it; if they would compile in Visual Studio 2012, you could compile them for RT. .NET programs didn't even need re-compiling. Drivers built using the modern driver kits were as easy to port as Win32 programs; some open-source drivers were successfully ported, and Pluggable even managed to get theirs USB Ethernet dongle's driver signed by MS before MS backpedaled on that. The bitch was getting past the stupid signature checks (most people were even less lucky than Pluggable). You could compile (where needed), and you could copy the programs to the tablet. You could even tell it to run them as Admin. But, without a jailbreak or a Microsoft signature (not just any Authenticode signature, it had to be from specific Microsoft keys), it wouldn't run.
That doomed the whole RT ecosystem. The app store's offerings were neither plentiful enough nor desirable enough to make the tablet worth its price (which was good for an 8-hour-battery laptop, but high for an ARM tablet). The initial jailbreak brought a surge of interest in porting open-source programs, and even led to the development of an x86-to-ARM dynamic recompilation (like emulation, but faster) layer that allowed running unmodified Win32 programs, including some old games. For months, MS didn't bother people who were finally getting to use their tablets as actually computers... and then 8.1 came out, and they blocked the jailbreak four different ways. There's a new jailbreak out now, but people just don't care much anymore. I don't know what idiot at MS thought that making RT even less useful was going to increase sales, but they traded in their .22 pocket footgun for a .50 fully automatic footrifle, and people just stopped bothering with it.
KOTOR (Knights Of The Old Republic) is different from "Star Wars: The Old Republic"; the latter is an MMO, currently supported, and more akin to WOW than to KOTOR except in its story aesthetic.
* Only if you don't include the weight and battery life among those specs. As a computer, it's overpriced. As a *portable* computer, it's just about smack in the middle of the pack for its class, price-wise.
* Switch the touch keyboard to the "Standard" or full layout. It has the meta keys you are looking for. You may need to enable it. In Win10, the setting is at Settings -> Devices -> Typing -> "Add the standard keyboard layout as a touch keyboard option".
* In desktop apps (i.e. non-Store apps), tap-and-hold is always right-click. In Win8.x Windows Store apps, right-clicking brings up the app bar; you can also achieve this by swiping in to the screen from above or below.
* I generally avoid the app store stuff - for me, its limitations aren't worth it, even in a touch environment, and that's without even getting into the fact that it's a DRM system.
For a "fundamentally broken" browser, it's very good at rendering web pages, has nicely configurable settings, is quite stable, and very fast. Do you have an actual objection to any aspect of it, or are you just talking out your ass? You don't even present a subjective, much less objective, fault in the browser. I could mention a few, but eh, none count as anything like "fundamentally broken".
Midori (http://midori-browser.org/) is pretty good for a fairly thin wrapper around WebKit. It's lacking a bunch of features, of course, but it has a tiny install and RAM footprint relative to mainstream browsers.
It's an OS commend injection vulnerability. Deserializing an object should not, by itself, ever execute arbitrary code. The only function that automatically runs on a deserialized object is that object's readObject function, which should in no way be usable to execute an arbitrary OS command. Apparently the writers of this library would find that concept bemusing.
This isn't a matter of
This is more a matter of
In case you missed it, the Apache Commons Collection library is, for some reason, shipping a self-firing footgun. They should patch that.
Apache Commons Collections contains an arbitrary shell command injection vulnerability reachable from the readObject function of one of its Serializable classes. Due to the way Java deserialization works, any Serializable class can be specified in a serialized Java object format, and unless there's code filtering the serialized binary data before deserializing it, that's enough to trigger the exploit.
Saying "Do not deserialize objects with executable code from the internet." sounds like a solution, but Java deserialization of objects passed on the wire is everywhere, and often even used pre-auth. Some of these things are management interfaces that definitely shouldn't be exposed to the Internet, but most of them will be exposed to the local network and that's still bad (arbitrary code execution in a server's management interface, callable by anybody who has access to the internal network even if they have no creds).
Fixing Commons Collection so that it can't be used for shell command injection would be a much more proper fix. Deserializing Java objects from the Internet *shouldn't* be dangerous; the simple act of deserializing an object should never inherently by harmful! Remember, the attacker can't force you to call any method of those objects. The attacker can't send objects that you don't already have class definitions for. The attacker can't add functions, or otherwise modify the class definitions. The only thing the attacker can be sure will happen is that the readObjection method - if it exists for the class in question - will execute. That's it. That should *NEVER* be enough to get arbitrary code execution!
They do, actually, at my local airport. It's something like $8 for domestic and $13 to Canada, but you can send home that little whatever that you forgot.
For the body scanner, put it on your sides. The plane of the scanner field only rotates across your front and back; it will miss anything directly on your sides. Wear slightly loose clothes and you can strap a weapon (or other object) a number of places outside the areas that the scanner "sees". Upper arms near your elbows (well out to the sides in "scanner pose"), sides of your torso unless you're super skinny, outsides of your legs if it doesn't show through your pants, insides of your legs (especially near the ankle) if you keep your feet a little wider than you should, etc.
For the baggage X-ray, just put "safe" stuff around the prohibited item. Tablet computers are great here; for some reason they're considered safe despite usually having plenty of metals, including potentially-dangerous lithium, in their chassis. Laptop power bricks and external hard drives are pretty hard to scan through; I've seen what they look like on the screens. Small items like pens, mint tins, coins, keys, flashdrives, jewelry, and so on can clutter the X-ray image and conceal stuff behind them, directly or by simply breaking up the outline sufficiently. A bag of toiletries containing a bunch of sub-3-oz tubes of this and that is *supposed* to be run through separately, but I've never once had a problem leaving it in my bag and I fly over a dozen times a year.
It's embarrassingly easy to get shit past those morons. Sometimes I do it by accident, like forgetting a pocketknife or bottle of soda. If it's not on the outer part of the bag, they usually miss it.
The TSA confiscates hundreds - over a thousand last year - of guns from law-abiding citizens (disproportionately Texans) who go armed so frequently, as a matter of habit analogous to wearing a watch of carrying a phone, that they forget to remove their weapons before going to the airport. I fully believe the vast majority of those are accidental. The amazing thing is that the TSA actually manages to find that many; I've certainly accidentally passed prohibited items (not firearms or munitions, but knives, liquids, and so on) through the scanners, and am not that surprised the GP could have gotten a box of ammo through without even trying to conceal it.
It's less about preventing fingerprinting and more about preventing third-party requests. For example, browsing Slashdot with Slashdot's ads ostensibly disabled, there are still eight different third-party requests (not counting stuff I've whitelisted, like jquery and other necessary evils) that my browser has blocked. That's not counting requests that the responses to those blocked requests themselves would have generated, which is usually several times as many (page loads third-party scripts A, B, and C, each of them loads another script and a tracking pixel, so you go from three blocked requests to nine third-party requests if you don't filter).
Not that I'm aware of. The closest is, oddly, IE; it has "tab grouping" that color-codes tabs so you can tell which tabs were opened from which other tabs. Still only along the top, though, and it doesn't actually show the hierarchy.
I'd really like to have tab trees in Pale Moon. At least Pale Moon supports switching tabs (Ctrl+Tab shortcut) in recently-used order... Firefox's default tab handling is shit (and not just for the location or lack of hierarchy).
Really, Mozilla? Copy a feature IE has had for years, ok, fine, good for you, have a cookie.
Make it completely obscure how to use it in the common scenario (i.e. not launching in Private Browsing mode), though? That's just... Stupid. Ridiculously stupid.
Fortunately for the world, but unfortunately for you, pretty much everybody is moving away from Flash. I block Flash by default. Three years ago I was asked to enable it for a site a few times a day, with an ugly grey box if I didn't. Now I don't remember needing to do so any time in the last few months, and I rarely even see the block indicator light up.
The funny thing is, this "tracking protection" feature is lifted wholesale from IE, which has had it since v9 (with a less-user-friendly version present in v8). The only difference is that, in IE, tracking protection is off by default but can be turned on (temporarily or as the new default) easily, whether in Private Browsing mode or not. In Firefox, so far as I can tell from the high-propaganda-low-content links in the TFS, it's only active in Private Browsing mode but at least it's active by default there. That's... progress, sure, but also somewhat misses the point.
I mean, most people on Firefox who care about privacy probably already figured out how to get Ghostery, Privacy Badger, AdBlock*, NoScript, and/or some other combination of helpful extensions installed. But still, there's something very funny about Mozilla coming up with a "block requests to third-party content to preserve privacy!" feature like it's 2011 (or 2009, but being very slightly less pussyfooted about it than MS was; in IE8 you had to enable the feature for each browser session and couldn't make it turn on by default). Making it active by default in Private Browsing mode is a good move, but scarcely an *impressive* one...
So, if the replication in different labs, by different teams, using different test apparatus, doesn't constitute replication... what does?
As I said above, you're full of shit. You know what's less scientific than not publishing a theory? Sticking your hands over your ears and shouting really loudly that something isn't real, no matter how many times it's demonstrated.
You're an idiot, with no better understanding of science than a young-earth creationist.
Yeah, you're full of shit.
NOT counting the inventors, it's been duplicated in four separate experiments at two different labs: China's Northwestern Polytechnical University in 2010, NASA's Advanced Propulsion Physics Lab (Eagleworks) in 2014 and twice in 2015 (the latter of which is the test being reported here).
Also, it's pretty clear you don't understand how scientific publication works. For that matter, you seem unclear on the entire concept of "science" itself. Publication is not, and can never by, science. Science is in the creation, testing, and refining or rejecting of theories. Publication is merely the process of distributing the result of science.
The problem is, nobody yet has a testable theory for how the drive works. They can (and have, repeatedly and replication) test *that* it works, but "I don't know why" is not a valid scientific explanation for an observed phenomenon, and will be rejected if anybody tries to publish "new space drive discovered" in a peer-reviewed journal. The theoretical explanation doesn't always come before the experimental results. However, the experimental results - not to be confused with the drive theory - can be and have been published.
Not having a scientific theory for an observed phenomenon doesn't make the phenomenon go away. It doesn't even make the phenomenon un-scientific. Not does it make measurements of the phenomenon unscientific.
Peer-reviewed publication of a tested theory is the end goal of science, but that doesn't make stuff which hasn't yet been published in a peer-reviewed journal "not science" any more than a person who hasn't yet returned home could be said to "not be vacationing".
You're confusing the EM Drive with a photon drive. The EM Drive requires a sealed resonant cavity. A photon drive requires an open-ended reflective emitter. Photon drives are, essentially, standard reaction drives that derive their thrust from the photons being shot out the back of the drive. The EM Drive - assuming it really works - is something else entirely, because there's nowhere for the photons to go; the net thrust they impart on the chamber seems like it ought to be zero.
As a side note, experimental results indicate that the EM Drive is about 400x the efficiency of a photon drive (1.3 microN / W for the EM Drive vs. 3.3 nanoN / W). This is one of the reasons (the other being that sealed cavity thing) that it's clearly *not* a photon drive in any sense we are familiar with.
The efficiency of photon drives is known very precisely, and can be taken into account with spacecraft... if such infinitesimal thrusts are even relevant. For satellites, the thrust generated by their antennas - which usually aren't even perfectly directional, and thus partially counteract themselves by sending some of the photons the wrong way - is probably lost in the noise of other trivial influences on their orbits.