For my next phone I'm gonna pony up and buy one with a pure full GNU Linux distro.
The problem is that there aren't many thing on the market yet.
Best contenders are :
Jolla they are the former Nokia engineers that used to work the Maemo/Meego system for Nokia'sr N800 / N900 / N9 series of phones until the whole Elop/Microsoft disaster shit-show happened. Now they are making Sailfish OS which is a continuation of the same development (but have now renamed the core from Meego to mer). They used to have some inhouse hardware (Jolla 1 Phone) then some manufacturer failure (Jolla Tablet), then some third party partner ship (Jolla C / Intex Aquasih). Their latest product is Sailfish X, done in partnership with Sony Open Devices, to Install Sailfish X on Sony Xperia X (single SIM version [the dual sim version isn't officially supported, but according to forum it works too), *not SIM-locked only* [SIM-locked phone cannot have their bootloader unlocked]). It's still an early beta, but if you're patient and willing to through the first few months of bugs, it might be worth giving it a try it's a full blown GNU/Linux under the hood, using modern features like Wayland, Systemd, etc. using RPM repositories for software distribution and significative developper community. Darbacks for your specific target is that to make deployment on smartphone easier, it does rely on same (closed source) drivers that the chipset manufacturer provide for smartphone (using an adaptation layer called libhybris), so you still have manufacturer blobs, and some bits of the infeface still aren't under a copy-left license yet (but Jolla plans to, and in the main time the source is visible any way, as the interface is mostly QML and Javascript anyway. With lots of patches available in the communities too)
Purism has successfully crowdfunded their librem 5 smartphone. Good news is that they plan to develop a 100% pure Linux opensource phone with no blobs (partly by selecting chip with 100% opensource support, and partly by isolating problematic chips like baseband modem into separate chips that only communicate with the main chipset over a standard protocole - there's no "baseband modem actually serving as the chipset's northbridge" as in Qualcomm) the drawbacks are that it's still in development (obviously), and that it uses a chipset that is either completely antique (currently their test are done on Freescale i.MX6, because that the only one with 100% opensource drivers supported by upstream kernel) or might be less exciting than other phone (they hope to be able to shift to FreeScale i.MX 8 as opensource support improves). they plan pure linux interfaces, mostly gnome and KDE Plasma Active (yet another QML-based interface).
Samsung is doing Tizen, which is a distant cousin of the Meego/Maemo family. But I don't know how much there is an active community
And I think that's about all currently active project of GNU/Linux phones, now that Ubuntu Touch has dropped the ball.
(Also, not interesting for you, but Sailfish OS, on their official commercial product support a proprietary compatibility layer - Alien-Dalvik by Myriad - that enables Android Apps (though currently only at 4.4 KitKat level). Purism has promised to consider some container based solution (andbox -based, perhaps ?) to bring compatibility to Android Apps. Tizen can download from their application store OpenMobile's Application Compatibility Layer.
So none of these will suffer from "not part of a big app ecosystem" networking effect)
What is this obession with phones so thin you could cut cheese with them ?
I see no direct benefit for the en user of a 4mm thick vs a 5mm phone. I only see an excuse for Apple to dump older connectors (like audio) on pretext of thigh space.
Actually, the real explanation behind this anecdote might be even worse, reaching Orwellian proportions, where the government of Big Brother was even able to know the intimates dreams and nightmares of this citizens.
Constantly listening wouldn't be very efficient : You'd need a phone that never goes into deep-sleep power saving, constantly processing sound, and probably constantly streaming the audio to the motherbase for analysis. I.e.: you'd be constantly consumer 24/7 the same level of resources as during a phone call. That's going to be very taxing on the battery life of the smartphone.
Instead it's much more probable that Facebook only collect occasional small cue (phone use, location, who else is on the same network but also pages browsed in any browser - due to their "Like button" javacsript code - etc. tons of small details about you). By collecting all these details, Facebook is able to actually predict (a bit) what you're thinking. Facebook had so much data about your friend that they more or less managed to predict he was going to be interested into meat grinders (or general meat-related products, and grinders happened to be what they had avilable as ads at the moment).
Remember that anecdote about target accidentally predicting a teen pregnancy ? And that was at a time when statistics where the dominant form of analysis. Nowadays Facebook and co have moved to deep neural nets and similar. They could make sense and see pattern out of tons of seemingly garbage data. Suddenly interests for meat grinder could have become predictible (At least in this case).
Unless both of you are way above 70 years old and you not only had a vasectomy, but even got your balls removed, I wouldn't trust 100% this.
Talking with my friends about their upcoming baby and boom next thing i know im getting pampers ads and investing in my childs education ads againsl all of sudden.
Given precedent at Target, It would be now a good idea to make a pregnancy test.
At that this at Target is rather old story. At a time where statistics was the best you could do. Since then we've moved past machine learning and into the real or deep neural nets. You can only guess what Facebook is able to infere and deduce about you..
Well, earlier this year, Lenovo announced ThinkPad A475 (Basically a T470 with AMD bristol bridge 7th gen APU).
Perhaps they will eventually annonce new additions to this family, upgraded to Ryzen Mobile (a probable A485, same base configuration, but an upgraded APU ?)
How many people do you see in practice carrying such "a full-sized, foldable keyboard" with them everywhere they go in case they need to reply to an email?
I do. But I don't mean that all smartphone maker should absolutely cater to my specific needs. I just mean that it's great that some OS manufacturer don't outright make it impossible, so the few of us who are interested can keep using it.
(like the early 4-parts Stowaway by Thinkoutide, sometime branded).
Yup, that's the technology. Geyes bought the license (and presumably some of the moulds). But I find the built quality of the Geyes a little bit less good that the original back when it was still ThinkOutisde. (My bluetooth ThinkOutside works perfectly. My Geyes has a few keys which are a little bit less responsive).
Once folded, it's smaller and more pockateable than a paperback. You can easily carry it in a cargo pants' side pockets. Or in a small back with a few other travel accessories (in my case : eBook, powerbank, roll-up micro-USB and plug-sized charger).
Just learn to read the docs if you insist on having esoteric options turned. In 2017, RAID56 are still marked incomplete.
Modern filesystem are a huge pile of diverse features, some are fully stable and used in production (e.g.: RAID0 and 1) other are still in development (e.g.: RAID56). Complain that BTRFS is completely crap because RAID5/6 isn't fully functionnal and production ready, is like complaining that the venerable XFS is utter crap because its copy-on-write and snapshotting doesn't work yet.
(and BTW, in-band deduplication doesn't even exist yet in BTRFS. ZFS is supposed to have it, but is an ultra-massive performance killer from what I've heard) (auto-defrag works, but is a write-perfomance killer. alternatives a no defrag at all, which is a read-performance killer. or using out-band defrag, which requires maintenance and kills snapshot correlation. all these are problem which are specific to copy-on-write (ZFS, BTRFS) and log-structured (UDF, F2FS) filesystems) (
ZFS works because it intentionally "Flattened the stack" -- Yes, this runs counter to the layered Unix approach
The problem is that ZFS implement this by rolling everything in the same "rampant layering violation" package. It is one single "flattened stack".
On the other hand, BTRFS shares as much code as possible with in-kernel facilities (it leverages "device mapper" routines that are used also by lvm, mdadm, mdraid, etc. it leverages in-kernel compression routine that are also used by the kernel loader and the crypto module, etc.) It's not as much a "rampant layering violation" as a wrapper against layer facilities already existing in kernel.
-- but sometimes that is NOT the best design decision.
So basically, the problem isn't the overall design, but that actual code re-use vs. re-write.
Meanwhile Oracle keeps flailing about with Btrfs.
Btrfs works. It's in kernel, It's a first class filesystem in opensuse, and its copy-on-write facilities are extensively used for versioning with snapper.
One nice thing about ZFS not being in upstream is that it is currently maintained and updated separate from the Linux kernel.
And that's actually a huge problem that makes it a major obstacle to its upstream adoption. Mainly due to code duplication.
ZFS (and its competitor BTRFS) is peculiar, because it's not just a filesystem. It's a whole integrated stack that includes a filesystem layer on the top, but also a volume management and replication layer underneath (ZFS and BTRFS on their own a the equivalent of a full EXT4 + LVM + MDADM stack).
That is a necessity, due to some features in these : e.g. the checksuming going on in the filesystem layer is also useful to determine correct copies in case of bitrot in the replication layer.
But how this is handled is the big difference between ZFS and BTRFS.
ZFS on Linux just packs all the needed bits together with it. It comes with its own volume management and replication code. That is a duplicate of functionnality existing elsewhere in the kernel. And duplication is always bad for maintenance.
BTRFS being developped on Linux tries to leverage as much as possible : - the Zstd compression currently being introduced to BTRFS, uses the same routines as the Zstd compression being introduced into the kernel loader : both leverage the in-kernel compression facilities of the crypto modules - the device mapper facilities are used by lvm, mdadm and dmraid but also by btrfs. There was a plan to develop code to support more than 2 parity blocks (more than RAID6), that would have been beneficial to both btrfs and mdadm.
That's why developers complain of boundaries/layers violation with ZFS but not about BTRFS. ZFS comes with its own tangled mess of layers, BTRFS is just a wrapper around facilities already existing in-kernel.
You're delusional. They couleave shipped a diesel generator
Actually forget about shipping the diesel generator. It's a hospital, it probably already has it's own generator. (Well, maybe not this peculiar hospital, but in general hospital have generators and you could ignore shipping them in the general picture).
and a few hundred gallons of fuel in less time.
Yeah ! Great, we can now run the hospital on monday ! Hey, what shall we do on tuesday, once around a hundred of gallons of fuel have been burned ?
Here lies your problem.
This is about restoring EMERGENCY power asap.
Generators are good for *emergency* power, as you say. i.e.: making sure that during the first few hours, there's some power, until the problem is solved.
It's only a very temporary backup. Then you hit the problem of supplying enough fuel to keep the generator going. That's the point of solar in sunny areas : it's not limited to a few hours.
This a small hospital, it doesn't probably have ginormous fuel reserve to hold any longer. The whole country has been destroyed, power won't be back after a few hours. The whole country has been destroyed, local fuel distribution won't be easy. It's remote area, shipping daily supplies of hundreds of gallon of fuel is going to be a logistical nightmare.
whereas native and web-based MUAs for smartphones don't except for the (presumably small) fraction of smartphone users who carry a Bluetooth keyboard everywhere.
It helps when the keyboard is a full-sized, foldable keyboard (like the early 4-parts Stowaway by Thinkoutide, sometime branded).
It also helps when the OS has been designed for note taking from the ground up (PalmOS back in the days) or is a full blown GNU/Linux where keyboard is natively supported (currently on Sailfish OS by Jolla).
We're surrounded by forest preserves and farmland, so most of the directions involve turn right, but get in the left lane to make an immediate left turn, which isn't conveyed well with garmen, apple maps, nor google maps.
Some brands (e.g.: Tomtom, even the older device as long as you've updated to a recent enough software version) can litteraly say that "Turn right, then keep left lane and prepare to turn left", with the logo on the screen showing that too (Big "Right turn" arrow, thin right arrow for "next", then Big "Left Turn" arrow).
Other brand (I've seen it on Volvo in-vehicle infotainment) don't have a special vocal message, but will open a split-screen pop-up next to the usual 3d over-the-shoulder view, with a bird's-eye view illustrating a complicated sequence of such turns.
(Which in theory is a nice idea, but in practice sucks, because you need to take your eyes of the road and look inside the car - as opposed to dedicated satnavs that you can stick on windshield just at the edge of your usual field of view. On the other hand, that specific Volvo is equipped with forward collision avoidance systems and could autonomously slam the break to avoid rear-ending the car in front while you're looking away. So never had an accident due to taking the eyes that far away from the road).
Does anybody compose serious emails using a mobile device?
Yes, except that my mobile devices has always had a keyboard.
Be it a connected full-sized foldable keyboard (Palm/Thinkoutside Stowaway keyboard for Palm IIIc, then similar for Palm Thungsten T3). Or a built-in slideable keyboard (Palm Pre, HP Pre3 - less comfortable but in a pinch could do) Or bluetooth connected full-sized foldable keyboard (Thinkoutside Stowaway bluetooth, on Tapwave Zodiac, on above mentionned webOS-powered pre, and currently on my Jolla). Recently even managed to find a revival of the same form factor (but from another company, the quality isn't as good as the original one) with a USB connector and thus compatible with anything that has USB OTG.
Given the size (and comfort) of a 4-parts W-shaped foldable keyboard, it doesn't exactly quality as a mobile device. At best the experience is more similar to a 2-in-1 convertible device.
But it's great to answers mail while having time to kill in the train. (European continent here around. We do have actually useful trains).
Why is scaling a big thing. If it works with N parameters, it will work with N+1.
One of the reasons is complexity of what the parameters describe and how they can be understood by the researcher.
The way it was done in aeronautics, could be compared to piloting a helicopter : - You have a position that you want to keep (easily described with 6 number giving coordinate and direction pointed to). - You have a bunch of controls (Cyclic, Collective, Anti-Torque, Throttle) with each subtly influencing each-other because of gyro effect. You optimise the main parameters (controls), and maybe you have an indirectly layer of a few implicit parameters as well (Yaw, Pitch, Roll, Raise rate) with controls not only directly but also indirectly mapping to them.
Nearly everything of the above makes sense to the researcher.
Deep neural nets could be considered the same, but turned up not only to 11, but to 10^11.
You have a picture, you have a dozen of layer, you get a bunch of parameters. You can use said parameters as a signature of the object looked at. You can give some general signification of the first few layers. (contrast/edge extraction, lines/directions extractions, texture extractions, etc...) but no single value make any sense by it self (compare to the Yaw, Pitch, Roll, Raise rate) ) Beyond this few layers things start to go really banana. Its hard to put an exact meaning to any single cell of this huge network. And you don't even need to consider them. The cells will find each their own internal meaning alone during the training.
You are basically doing the in-silico equivalent of training pigeons to peck at picture of cities. You have a general idea of how an animal's visual system works. You can even go poke inside its brain with electrode to measure local variation. But you can't really comprehend what every single synapse between brain's neuron are in charge of. At this scale it becomes meaningless.
Instead you count on some general forms of test to make sure that process works as it should. (random example : you can tweak noise until is makes a pre-trained system light up. The noise will become a weird surealist distorted hallucination of what you trained your neural net for - search google image for dog nebula).
The sheer scale of the stuff make it meaningless to comprehend in details. You consider it at a higher level. You don't think about logical gate of silicon transistors when you think about information flow across the internet. Even if the internet is an interconnection of network, which in turn are interconnected computer, which in trun contains lots of chips, which in turn a composed of myriads of logic gates. But nobody thinks about the logic gates when solving internet problems. And the same way nobody thinks about single parameters when considering deep-neural-nets.
The second thing is that at this scale, you take a lot of shortcut to propagate the "signal" (i.e.: how each parameter influence the next, how each cell of the network is connected to the next one). And you train the thing until it more or less produce acceptable result, not until it stays stable. Otherwise you would be asymptotically approaching a wall where there is simply not enough existing computing power to throw at it.
Or hope that the ones running the exit node doesn't also have thumbscrews on as much as a single entity that issues certificates and is a root CA in the certificate stores of most browsers. How much are you willing to bet that TLAs in the US cannot get certs issued by one of the many US CAs in order to monitor traffic to a given web site?
Like I've written just after that, it boils down to : - kicking out CA which are known to issue bogus certificate to third parties (par of the reason why China's CA and a few other got kicked out of every modern browser) - certificate pinning and various other example of techniques which help make sure that the certificate you're seeing is the right certificate and not a bogus one issued by some government-controlled CA that you happen to trust. (Such measure can already detect when a content distribution system hasn't synchronized their certificates)
And again, like I've said nearly the top of this discussion : if the NSA, the FSB and the Mossad want your ass, TOR isn't a magic bullet that can save you (and there's no single thing that could save you either). But TOR is nonetheless a step in the right direction that can limit the damage that small player can do (and a building block toward a more comprehensive solution infrastructure that can hamper a bit Mossad-level targetting)
An.onion address isn't much help if any part of the rest of the URL is on a special interest list. azix723czou5pTr1k.onion/illegal/content/terrorists_handbook.pdf or th3b9eex7781fgp.onion/vajiralongkorn-buggering-a-pig.png are flags as good as any.
I think you definitely need to document yourself how TOR work in general (and how.onion addresses work in peculiar). (And also how HTTPS work, by the way)
TOR is a layered encryption scheme (hence the "onion" part of the name). Each layer is a cryptographic public key layer. Only a node with the corresponding private key can peel a layer and see what is inside. Inside there might be: - (for all nodes) another encrypted layer, in which case the node forward it to the next node, identified by the public key in that new layer. - (for exit nodes) an exit node might find underneath instructions to contact a resource on the regular net - (for hidden service) an node with hidden service might find underneath instructions to pull data out of its own web server to which it is attached
If the target address is.onion: in that case, the request NEVER reaches an exit node. One of the node on the route actually happens to have a webserver attached to it, and when peeling the onion layer, get instruction to return some data from that server, instead of passing the onion to the next node in line. No exit node will ever see the URL. Only the hidden server will ever know which file got send.
The only thing I'm simplifying here is the gymnastics in setting up a circuit between the user and the server. (It's done a way to guarantee each-other's anonymity, both end points have a say on the layers between them).
An exit node might see an URL as you mention, only if: - it's a genuine web address (like slashdot.org) - the traffic is in plain unencrypted HTTP. In this case, the exit node will see a conenction requrest to the:80 TCP port of the server handling slashdot.org, and then will notice in the plain stream the "GET/path/image.png" stanza. So only in these circumstances does an entity owning an exit node knows exactly which URL you visit.
If the traffic is HTTPS: in that case, the exit node sees the conenction to the:443 TCP port. But from this point onward, the browser and the web server negociate a connection. Only an entity possessing the private keys of webserver could successfully impersonate the server and pull a man-in-the-middle. Other wise you need to hope that the browser is stupid enough to trust your shady certificate authority (e.g.: You're China, and thus you can issue a certificate for Google.cn signed by the China CA trusted by some gullible browser that hasn't removed this CA yet from their list like any other modern browser) and the user uses no certificate pinning plugin (complaining that the google certificate suddenly isn't signed by Google's own CA but by China). Without this, the HTTPS is completely opaque. You don't see the full visited URL.
Never mind that the.onion addresses are persistent for long enough that the surveillance teams who also browse the illegal content can easily add them to their own scan lists.
Nice for them to add it to a list but WHAT are they doing to scan with this list ? No exit node is ever going to observing that URL.
The only place where this URL will be seens is on the log of the actual server. Either the actual position of this server is unknown. Or the adversary actually OWNS the server. At which point the logs of the server aren't the biggest problem anymore : now the advesary can honney trap all they want as they control the server.
I think you misunderstand how Tor works. There will always be an exit node.
From my investigation of the matter it looks to be some sort of multi-variate analysis in drag. Uninteresting. Basically you get guys sitting around twiddling knobs. Finding the right parameters which works for a little bit and then you start knob twiddling again to find the next ones.
Except for 1 key difference. With Deep-Neural-Nets, the knobs twiddle themselves alone.
DNN get inspiration of how some neural network work in the nature (e.g.: a column in the primary visual cortex of the brain) to design thing that you can throw at problems, and which will autonomously train themselves.
Some years back I wrote a day trading program for a friend. It dynamically changed its behavior depending on the market signals and the rules he gave it (stops, buys, shift to a different stock etc.) which he found useful. Now that was fun.
These older program require you to have precise criteria in advance.
That works perfectly well with clearly codified problem - the friend has a clear set of rules that need implementation.
That completely fails for more vague problem ("detect a face") - it would be possible in theory to design a set of rules that can detect a face - a Haar Cascade. But designing such set of rules is extremely complex and cumbersome. And each time you need something new ("detect if there's a bird"), you would need to repeat all the hard work to invent yet another set of rules. At that point, better take an advice from how mother nature solved the problem (by using stacks of neural network in a columns) and simply throw a DNN (e.g: a Convolution Neural Net - a ConvNet) at the problem, and watch it self organize and come up with a solution to your problem.
but being able to fingerprint any users who use that exit node as little as once. {...} and check the fingerprint of those requests against big entities like Google, PayPal and banks.
If any of the accesses to a highly illegal source have fairly unique fingerprint that any entity is able to match to a person, you get a court order to search that person's computer for evidence.
(Note: you're answering to the wrong paragraph, I've written about finger printing in the next one).
Yes, but that require a finger-printable browser.
As I've mentioned, the Tor bundle goes to great lenght to make sure that the packaged Tor Browser is as unremarkable as possible. (Characteristics shared by hundreds of thousands)
Also in the specific case of "high illegal source": if even The Piratebay and Duck Duck Go have.onion addresses (as I've mentioned in my 3rd part), you can bet that the juicy stuff that law enforcement would be aiming (whatever is the current descendant of Silk Road ?) has also an onion address and no exit node will ever see the traffic. There won't be any log to grep.
Palm IIIc was the first to have these characteristics on a PalmOS running device, a whole 7 years before the first iPhone. (Followed shortly by similar specs from Visor) Psion Series 7 was the first to have them on an EPOC running device, around the same time as Palm, a little bit before Sony Ericsson (same OS).
Though you might argue that the rounded corner on these devices wasn't a design choice, but a limitation to the molded plastic cases (a tiny bit more durable than plastic sharp edges), but the rest : a black screen (actual theme chosen by the user: default was often white, but lots of other colors available, including black), and a colorful grid of apps was there. (Including 3rd party apps, way before Apple even considered starting AppStore).
That's actual hardware being shipped and used back at a time when Apple didn't even had the idea to consider producing phones (having been quite recently been burned by the Newton).
---
Note: Though the Palm IIIc doesn't qualify as smartphone but only a PDA (IrDA only networking. No cell), all the other did support adding a cell modem to expand functionality into what would nowadays be considered as smartphones. (Visor + their cell modem expansion board is what more or less bootstrapped the whole small slab form factor used by all modern smartphones).
There might be a very slim chance that these first 150k units sold weren't bought by Snap users, but by Facebook employee asked to buy them so Snap's team would wrongly think that there some existing interest into this crap, order 500k more units produceds and then bankrupt with their unsold stock, enabling the Zuck to finally buy them out.
Sound like bond vilain scheme, but I still believe that there is a tiny chance that this might be true.
The problem with deflector dishes is that the ship is travelling at (say, warp 2, which is four times the speed of light) and the deflector dish puts out a beam which travels faster than that forward of the ship to sweep away all that pesky interstellar dust.
Two things: - Alcubierre drives, the theoretical physics concept around which the fictional warp drives are based do not actually move the ship. At all. The ship stays completely immobile in its own frame of reference. (There wouldn't be a way to move it past speed of light anyway). What you move it the frame of reference it self. You bend the space time it self. You contract it in front of the ship, and expand it behind. And unlike speed of things which is limited (at C, the speed of light), space-time bending isn't limited (How the hell to you think our real-world astronomers can observe the distant past by looking at far away points in the space ? if our solar system was just a moving object, it would obligatory move slower than speed of light, and the light emitted in the distant past would have "over-taken" us and would not be observable anymore. The trick is that the space time of our actual universe did expand it self. More space was "created" between the objects, so that now they are further apart, and we can still catch "glimpse" of the beginning of the universe - some of these past images haven't reach us yet, because these image suddenly have way more space to travel to reach us because of that space-time expansion) The only difference is that Alcubiere drive is a completely theoretical concept. It might not even be doable in the real world : it might happen that distorting the space time this way could require more energy than contain in the universe that you're trying to distort (it took a whole bigbang to expand our universe). Whereas in Star Trek they just use dilithium crystals or some other fictional stuff in their warp core and can warp around freely.
- Speed of light. You're reasoning "the deflector dish puts out a beam which travels faster than that forward of the ship" is based on old classical physics (the speed of some launched from a moving something is the sum of both speeds : a photon launched from a ship travelling near the light speed would it self be launched at nearly twice the lights speed). Classical physics at that speed don't work and give wrong results (there's no such thing as an object moving at twice the light speed). You're entering the realm of relativist physics: No matter what, the light speed (in vacuum) is constant and the same same every where in all referential. When an object is moving, from the point of view of the object the radiation it's shining forward will travel at exactly 1 C. From your point of view as an observer, the radiation of the deflector will travel at exactly 1 C *too*. The thing that will change is the time and space. The scales will seems squished and time will seem running slow, so at the end, both the ship and observer will see the same distance/time = speed of light for the radion. The speed of light doesn't change, is the distance and time which end up being different.
There's a bunch of math to compute all this, but then... (appropriate citation, in Bone's voice) I'm a doctor, Jim ! Not an astrophysicist)
---
(Also not mentioned in your post, but also relevant to the discussion of Star Trek technology : artificial gravity and inertial dampeners. General relativity. Which basically states that gravity actually works by playing around with space time too. Except this time, it isn't by expanding or contracting space, but by curving it. Objects aren't actually "attracted" to each other. They simply travel on straight lines (imagine a point travelling on grid on a sheet of paper), but the "straight lines" them selves are curved by the presence of mass (if you draw a sun in the middle of your sheet of paper, the grid suddenly isn't squares anymore but spirals that head towa
It wasn't even good at emulating hardware used by games and creativity programs (music players, graphics stuff etc.)
Depends on the hardware.
If it's some rare custom ISA card hardware : yes it's going to be problematic. (e.g.: some custom ISA controller used by the photo scanner of some graphics creativity program, or a custom ISA multi-channel DAC used by scientific equipment).
If it talks to the computer using a standard way (e.g.: talks over a standard COM port, a MIDI port or - rarely back then - talks over the network using some packet driver) or if the ISA card is a common one (nearly any sound card, including Garvis Ultrasound) : it works pretty well.
That even include emulating some quirks and hacks (TweakMode/ModeX type of graphical modes, abusing the NTSC composite color clash to generate more than the 4 CGA colors, etc.) or even emulating devices connected to the virtual PC (there are software to emulate a full blown MT32 synth connected to the dosbox' MIDI bus).
There's actually atmospheric drag on the ISS such that, without periodic corrections, will drag it down out of orbit. That's true of ANY low earth orbit satellite, of course.
At it's current altitude, the ISS orbit decays about 100m per day. And the lower it dips into the upper atmosphere, the faster the rate of decay becomes. Without correctional boosts, the ISS would probably fall from they sky relatively quickly. I've seen estimations of approximately six months or so.
Which is entirely the point of using that orbit. Anything else beside the ISS (i.e.: debris) will lack said boost and will eventually fall from the sky rather quickly, which means that such low orbit are relatively clean and only contain the few man-made object that can actually boost and nothing else: this means a lot less risks of debris/micro-meteorite impact and a lot less necessary collision-avoidance corrections.
You can bet that if Microsoft tries to actually seriously implement a log-structured (e.g.: actually decided to use UDF beyond optical and portable flash media) or copy-on-write filesystem (e.g.: ZFS and BTRFS on NT kernels) that supports version control, they'll botch it and there will be an exploit found making the older copies also editable by a non-admin user (the ransomware could purge the older copies and only leave the encrypted version).
Slashdot Mirror
For my next phone I'm gonna pony up and buy one with a pure full GNU Linux distro.
The problem is that there aren't many thing on the market yet.
Best contenders are :
Now they are making Sailfish OS which is a continuation of the same development (but have now renamed the core from Meego to mer).
They used to have some inhouse hardware (Jolla 1 Phone) then some manufacturer failure (Jolla Tablet), then some third party partner ship (Jolla C / Intex Aquasih). Their latest product is Sailfish X, done in partnership with Sony Open Devices, to Install Sailfish X on Sony Xperia X (single SIM version [the dual sim version isn't officially supported, but according to forum it works too), *not SIM-locked only* [SIM-locked phone cannot have their bootloader unlocked]). It's still an early beta, but if you're patient and willing to through the first few months of bugs, it might be worth giving it a try
it's a full blown GNU/Linux under the hood, using modern features like Wayland, Systemd, etc. using RPM repositories for software distribution and significative developper community.
Darbacks for your specific target is that to make deployment on smartphone easier, it does rely on same (closed source) drivers that the chipset manufacturer provide for smartphone (using an adaptation layer called libhybris), so you still have manufacturer blobs, and some bits of the infeface still aren't under a copy-left license yet (but Jolla plans to, and in the main time the source is visible any way, as the interface is mostly QML and Javascript anyway. With lots of patches available in the communities too)
Good news is that they plan to develop a 100% pure Linux opensource phone with no blobs (partly by selecting chip with 100% opensource support, and partly by isolating problematic chips like baseband modem into separate chips that only communicate with the main chipset over a standard protocole - there's no "baseband modem actually serving as the chipset's northbridge" as in Qualcomm)
the drawbacks are that it's still in development (obviously), and that it uses a chipset that is either completely antique (currently their test are done on Freescale i.MX6, because that the only one with 100% opensource drivers supported by upstream kernel) or might be less exciting than other phone (they hope to be able to shift to FreeScale i.MX 8 as opensource support improves).
they plan pure linux interfaces, mostly gnome and KDE Plasma Active (yet another QML-based interface).
And I think that's about all currently active project of GNU/Linux phones, now that Ubuntu Touch has dropped the ball.
(Also, not interesting for you, but Sailfish OS, on their official commercial product support a proprietary compatibility layer - Alien-Dalvik by Myriad - that enables Android Apps (though currently only at 4.4 KitKat level).
Purism has promised to consider some container based solution (andbox -based, perhaps ?) to bring compatibility to Android Apps.
Tizen can download from their application store OpenMobile's Application Compatibility Layer.
So none of these will suffer from "not part of a big app ecosystem" networking effect)
What is this obession with phones so thin you could cut cheese with them ?
I see no direct benefit for the en user of a 4mm thick vs a 5mm phone.
I only see an excuse for Apple to dump older connectors (like audio) on pretext of thigh space.
Actually, the real explanation behind this anecdote might be even worse, reaching Orwellian proportions, where the government of Big Brother was even able to know the intimates dreams and nightmares of this citizens.
Constantly listening wouldn't be very efficient :
You'd need a phone that never goes into deep-sleep power saving, constantly processing sound, and probably constantly streaming the audio to the motherbase for analysis. I.e.: you'd be constantly consumer 24/7 the same level of resources as during a phone call.
That's going to be very taxing on the battery life of the smartphone.
Instead it's much more probable that Facebook only collect occasional small cue (phone use, location, who else is on the same network but also pages browsed in any browser - due to their "Like button" javacsript code - etc. tons of small details about you). By collecting all these details, Facebook is able to actually predict (a bit) what you're thinking. Facebook had so much data about your friend that they more or less managed to predict he was going to be interested into meat grinders (or general meat-related products, and grinders happened to be what they had avilable as ads at the moment).
Remember that anecdote about target accidentally predicting a teen pregnancy ? And that was at a time when statistics where the dominant form of analysis.
Nowadays Facebook and co have moved to deep neural nets and similar. They could make sense and see pattern out of tons of seemingly garbage data.
Suddenly interests for meat grinder could have become predictible (At least in this case).
my wife and i are done having kids.
Unless both of you are way above 70 years old and you not only had a vasectomy, but even got your balls removed,
I wouldn't trust 100% this.
Talking with my friends about their upcoming baby and boom next thing i know im getting pampers ads and investing in my childs education ads againsl all of sudden.
Given precedent at Target, It would be now a good idea to make a pregnancy test.
At that this at Target is rather old story. At a time where statistics was the best you could do. Since then we've moved past machine learning and into the real or deep neural nets. You can only guess what Facebook is able to infere and deduce about you..
Well, earlier this year, Lenovo announced ThinkPad A475 (Basically a T470 with AMD bristol bridge 7th gen APU).
Perhaps they will eventually annonce new additions to this family, upgraded to Ryzen Mobile (a probable A485, same base configuration, but an upgraded APU ?)
Let's hope...
How many people do you see in practice carrying such "a full-sized, foldable keyboard" with them everywhere they go in case they need to reply to an email?
I do.
But I don't mean that all smartphone maker should absolutely cater to my specific needs.
I just mean that it's great that some OS manufacturer don't outright make it impossible,
so the few of us who are interested can keep using it.
(like the early 4-parts Stowaway by Thinkoutide, sometime branded).
Did it look anything like Portable Folding External USB Wired Keyboard for Cell Phone / Tablet PC - Black?
Yup, that's the technology. Geyes bought the license (and presumably some of the moulds).
But I find the built quality of the Geyes a little bit less good that the original back when it was still ThinkOutisde.
(My bluetooth ThinkOutside works perfectly. My Geyes has a few keys which are a little bit less responsive).
Once folded, it's smaller and more pockateable than a paperback.
You can easily carry it in a cargo pants' side pockets.
Or in a small back with a few other travel accessories (in my case : eBook, powerbank, roll-up micro-USB and plug-sized charger).
Just ask SUSE:
Just learn to read the docs if you insist on having esoteric options turned.
In 2017, RAID56 are still marked incomplete.
Modern filesystem are a huge pile of diverse features, some are fully stable and used in production (e.g.: RAID0 and 1) other are still in development (e.g.: RAID56).
Complain that BTRFS is completely crap because RAID5/6 isn't fully functionnal and production ready, is like complaining that the venerable XFS is utter crap because its copy-on-write and snapshotting doesn't work yet.
(and BTW, in-band deduplication doesn't even exist yet in BTRFS. ZFS is supposed to have it, but is an ultra-massive performance killer from what I've heard)
(auto-defrag works, but is a write-perfomance killer. alternatives a no defrag at all, which is a read-performance killer. or using out-band defrag, which requires maintenance and kills snapshot correlation.
all these are problem which are specific to copy-on-write (ZFS, BTRFS) and log-structured (UDF, F2FS) filesystems)
(
In contradistinction ZFS takes a holistic, unified approach:
* Volument Management <--> File Management <--> Block
{...}
ZFS works because it intentionally "Flattened the stack" -- Yes, this runs counter to the layered Unix approach
The problem is that ZFS implement this by rolling everything in the same "rampant layering violation" package.
It is one single "flattened stack".
On the other hand, BTRFS shares as much code as possible with in-kernel facilities (it leverages "device mapper" routines that are used also by lvm, mdadm, mdraid, etc. it leverages in-kernel compression routine that are also used by the kernel loader and the crypto module, etc.)
It's not as much a "rampant layering violation" as a wrapper against layer facilities already existing in kernel.
-- but sometimes that is NOT the best design decision.
So basically, the problem isn't the overall design, but that actual code re-use vs. re-write.
Meanwhile Oracle keeps flailing about with Btrfs.
Btrfs works. It's in kernel, It's a first class filesystem in opensuse, and its copy-on-write facilities are extensively used for versioning with snapper.
One nice thing about ZFS not being in upstream is that it is currently maintained and updated separate from the Linux kernel.
And that's actually a huge problem that makes it a major obstacle to its upstream adoption.
Mainly due to code duplication.
ZFS (and its competitor BTRFS) is peculiar, because it's not just a filesystem. It's a whole integrated stack that includes a filesystem layer on the top, but also a volume management and replication layer underneath (ZFS and BTRFS on their own a the equivalent of a full EXT4 + LVM + MDADM stack).
That is a necessity, due to some features in these : e.g. the checksuming going on in the filesystem layer is also useful to determine correct copies in case of bitrot in the replication layer.
But how this is handled is the big difference between ZFS and BTRFS.
ZFS on Linux just packs all the needed bits together with it.
It comes with its own volume management and replication code.
That is a duplicate of functionnality existing elsewhere in the kernel.
And duplication is always bad for maintenance.
BTRFS being developped on Linux tries to leverage as much as possible :
- the Zstd compression currently being introduced to BTRFS, uses the same routines as the Zstd compression being introduced into the kernel loader : both leverage the in-kernel compression facilities of the crypto modules
- the device mapper facilities are used by lvm, mdadm and dmraid but also by btrfs. There was a plan to develop code to support more than 2 parity blocks (more than RAID6), that would have been beneficial to both btrfs and mdadm.
That's why developers complain of boundaries/layers violation with ZFS but not about BTRFS.
ZFS comes with its own tangled mess of layers, BTRFS is just a wrapper around facilities already existing in-kernel.
You're delusional. They couleave shipped a diesel generator
Actually forget about shipping the diesel generator.
It's a hospital, it probably already has it's own generator.
(Well, maybe not this peculiar hospital, but in general hospital have generators and you could ignore shipping them in the general picture).
and a few hundred gallons of fuel in less time.
Yeah ! Great, we can now run the hospital on monday !
Hey, what shall we do on tuesday, once around a hundred of gallons of fuel have been burned ?
Here lies your problem.
This is about restoring EMERGENCY power asap.
Generators are good for *emergency* power, as you say.
i.e.: making sure that during the first few hours, there's some power, until the problem is solved.
It's only a very temporary backup.
Then you hit the problem of supplying enough fuel to keep the generator going.
That's the point of solar in sunny areas : it's not limited to a few hours.
This a small hospital, it doesn't probably have ginormous fuel reserve to hold any longer.
The whole country has been destroyed, power won't be back after a few hours.
The whole country has been destroyed, local fuel distribution won't be easy.
It's remote area, shipping daily supplies of hundreds of gallon of fuel is going to be a logistical nightmare.
whereas native and web-based MUAs for smartphones don't except for the (presumably small) fraction of smartphone users who carry a Bluetooth keyboard everywhere.
It helps when the keyboard is a full-sized, foldable keyboard (like the early 4-parts Stowaway by Thinkoutide, sometime branded).
It also helps when the OS has been designed for note taking from the ground up (PalmOS back in the days)
or is a full blown GNU/Linux where keyboard is natively supported (currently on Sailfish OS by Jolla).
We're surrounded by forest preserves and farmland, so most of the directions involve turn right, but get in the left lane to make an immediate left turn, which isn't conveyed well with garmen, apple maps, nor google maps.
Some brands (e.g.: Tomtom, even the older device as long as you've updated to a recent enough software version) can litteraly say that "Turn right, then keep left lane and prepare to turn left", with the logo on the screen showing that too (Big "Right turn" arrow, thin right arrow for "next", then Big "Left Turn" arrow).
Other brand (I've seen it on Volvo in-vehicle infotainment) don't have a special vocal message, but will open a split-screen pop-up next to the usual 3d over-the-shoulder view, with a bird's-eye view illustrating a complicated sequence of such turns.
(Which in theory is a nice idea, but in practice sucks, because you need to take your eyes of the road and look inside the car - as opposed to dedicated satnavs that you can stick on windshield just at the edge of your usual field of view.
On the other hand, that specific Volvo is equipped with forward collision avoidance systems and could autonomously slam the break to avoid rear-ending the car in front while you're looking away. So never had an accident due to taking the eyes that far away from the road).
Does anybody compose serious emails using a mobile device?
Yes, except that my mobile devices has always had a keyboard.
Be it a connected full-sized foldable keyboard (Palm/Thinkoutside Stowaway keyboard for Palm IIIc, then similar for Palm Thungsten T3).
Or a built-in slideable keyboard (Palm Pre, HP Pre3 - less comfortable but in a pinch could do)
Or bluetooth connected full-sized foldable keyboard (Thinkoutside Stowaway bluetooth, on Tapwave Zodiac, on above mentionned webOS-powered pre, and currently on my Jolla).
Recently even managed to find a revival of the same form factor (but from another company, the quality isn't as good as the original one) with a USB connector and thus compatible with anything that has USB OTG.
Given the size (and comfort) of a 4-parts W-shaped foldable keyboard, it doesn't exactly quality as a mobile device.
At best the experience is more similar to a 2-in-1 convertible device.
But it's great to answers mail while having time to kill in the train.
(European continent here around. We do have actually useful trains).
Why is scaling a big thing. If it works with N parameters, it will work with N+1.
One of the reasons is complexity of what the parameters describe and how they can be understood by the researcher.
The way it was done in aeronautics, could be compared to piloting a helicopter :
- You have a position that you want to keep (easily described with 6 number giving coordinate and direction pointed to).
- You have a bunch of controls (Cyclic, Collective, Anti-Torque, Throttle) with each subtly influencing each-other because of gyro effect.
You optimise the main parameters (controls), and maybe you have an indirectly layer of a few implicit parameters as well (Yaw, Pitch, Roll, Raise rate) with controls not only directly but also indirectly mapping to them.
Nearly everything of the above makes sense to the researcher.
Deep neural nets could be considered the same, but turned up not only to 11, but to 10^11.
You have a picture, you have a dozen of layer, you get a bunch of parameters. You can use said parameters as a signature of the object looked at.
You can give some general signification of the first few layers. (contrast/edge extraction, lines/directions extractions, texture extractions, etc...) but no single value make any sense by it self (compare to the Yaw, Pitch, Roll, Raise rate) )
Beyond this few layers things start to go really banana.
Its hard to put an exact meaning to any single cell of this huge network. And you don't even need to consider them. The cells will find each their own internal meaning alone during the training.
You are basically doing the in-silico equivalent of training pigeons to peck at picture of cities.
You have a general idea of how an animal's visual system works. You can even go poke inside its brain with electrode to measure local variation.
But you can't really comprehend what every single synapse between brain's neuron are in charge of. At this scale it becomes meaningless.
Instead you count on some general forms of test to make sure that process works as it should.
(random example : you can tweak noise until is makes a pre-trained system light up. The noise will become a weird surealist distorted hallucination of what you trained your neural net for - search google image for dog nebula).
The sheer scale of the stuff make it meaningless to comprehend in details. You consider it at a higher level.
You don't think about logical gate of silicon transistors when you think about information flow across the internet.
Even if the internet is an interconnection of network, which in turn are interconnected computer, which in trun contains lots of chips, which in turn a composed of myriads of logic gates.
But nobody thinks about the logic gates when solving internet problems.
And the same way nobody thinks about single parameters when considering deep-neural-nets.
The second thing is that at this scale, you take a lot of shortcut to propagate the "signal" (i.e.: how each parameter influence the next, how each cell of the network is connected to the next one). And you train the thing until it more or less produce acceptable result, not until it stays stable. Otherwise you would be asymptotically approaching a wall where there is simply not enough existing computing power to throw at it.
Or hope that the ones running the exit node doesn't also have thumbscrews on as much as a single entity that issues certificates and is a root CA in the certificate stores of most browsers.
How much are you willing to bet that TLAs in the US cannot get certs issued by one of the many US CAs in order to monitor traffic to a given web site?
Like I've written just after that, it boils down to :
- kicking out CA which are known to issue bogus certificate to third parties (par of the reason why China's CA and a few other got kicked out of every modern browser)
- certificate pinning and various other example of techniques which help make sure that the certificate you're seeing is the right certificate and not a bogus one issued by some government-controlled CA that you happen to trust.
(Such measure can already detect when a content distribution system hasn't synchronized their certificates)
And again, like I've said nearly the top of this discussion : if the NSA, the FSB and the Mossad want your ass, TOR isn't a magic bullet that can save you (and there's no single thing that could save you either). But TOR is nonetheless a step in the right direction that can limit the damage that small player can do (and a building block toward a more comprehensive solution infrastructure that can hamper a bit Mossad-level targetting)
An .onion address isn't much help if any part of the rest of the URL is on a special interest list. azix723czou5pTr1k.onion/illegal/content/terrorists_handbook.pdf or th3b9eex7781fgp.onion/vajiralongkorn-buggering-a-pig.png are flags as good as any.
I think you definitely need to document yourself how TOR work in general (and how .onion addresses work in peculiar).
(And also how HTTPS work, by the way)
TOR is a layered encryption scheme (hence the "onion" part of the name).
Each layer is a cryptographic public key layer. Only a node with the corresponding private key can peel a layer and see what is inside.
Inside there might be:
- (for all nodes) another encrypted layer, in which case the node forward it to the next node, identified by the public key in that new layer.
- (for exit nodes) an exit node might find underneath instructions to contact a resource on the regular net
- (for hidden service) an node with hidden service might find underneath instructions to pull data out of its own web server to which it is attached
If the target address is .onion :
in that case, the request NEVER reaches an exit node.
One of the node on the route actually happens to have a webserver attached to it, and when peeling the onion layer, get instruction to return some data from that server, instead of passing the onion to the next node in line.
No exit node will ever see the URL.
Only the hidden server will ever know which file got send.
The only thing I'm simplifying here is the gymnastics in setting up a circuit between the user and the server.
(It's done a way to guarantee each-other's anonymity, both end points have a say on the layers between them).
An exit node might see an URL as you mention, only if : :80 TCP port of the server handling slashdot.org, and then will notice in the plain stream the "GET /path/image.png" stanza. So only in these circumstances does an entity owning an exit node knows exactly which URL you visit.
- it's a genuine web address (like slashdot.org)
- the traffic is in plain unencrypted HTTP.
In this case, the exit node will see a conenction requrest to the
If the traffic is HTTPS : :443 TCP port. But from this point onward, the browser and the web server negociate a connection.
in that case, the exit node sees the conenction to the
Only an entity possessing the private keys of webserver could successfully impersonate the server and pull a man-in-the-middle. Other wise you need to hope that the browser is stupid enough to trust your shady certificate authority (e.g.: You're China, and thus you can issue a certificate for Google.cn signed by the China CA trusted by some gullible browser that hasn't removed this CA yet from their list like any other modern browser) and the user uses no certificate pinning plugin (complaining that the google certificate suddenly isn't signed by Google's own CA but by China).
Without this, the HTTPS is completely opaque. You don't see the full visited URL.
Never mind that the .onion addresses are persistent for long enough that the surveillance teams who also browse the illegal content can easily add them to their own scan lists.
Nice for them to add it to a list but WHAT are they doing to scan with this list ?
No exit node is ever going to observing that URL.
The only place where this URL will be seens is on the log of the actual server.
Either the actual position of this server is unknown.
Or the adversary actually OWNS the server. At which point the logs of the server aren't the biggest problem anymore : now the advesary can honney trap all they want as they control the server.
I think you misunderstand how Tor works. There will always be an exit node.
Nope, no. No, no, no, no.
From my investigation of the matter it looks to be some sort of multi-variate analysis in drag. Uninteresting. Basically you get guys sitting around twiddling knobs. Finding the right parameters which works for a little bit and then you start knob twiddling again to find the next ones.
Except for 1 key difference. With Deep-Neural-Nets, the knobs twiddle themselves alone.
DNN get inspiration of how some neural network work in the nature (e.g.: a column in the primary visual cortex of the brain) to design thing that you can throw at problems, and which will autonomously train themselves.
Some years back I wrote a day trading program for a friend. It dynamically changed its behavior depending on the market signals and the rules he gave it (stops, buys, shift to a different stock etc.) which he found useful. Now that was fun.
These older program require you to have precise criteria in advance.
That works perfectly well with clearly codified problem - the friend has a clear set of rules that need implementation.
That completely fails for more vague problem ("detect a face") - it would be possible in theory to design a set of rules that can detect a face - a Haar Cascade. But designing such set of rules is extremely complex and cumbersome. And each time you need something new ("detect if there's a bird"), you would need to repeat all the hard work to invent yet another set of rules.
At that point, better take an advice from how mother nature solved the problem (by using stacks of neural network in a columns) and simply throw a DNN (e.g: a Convolution Neural Net - a ConvNet) at the problem, and watch it self organize and come up with a solution to your problem.
It's the modern-day equivalent of training pigeons to peck a city images to steer a missile.
but being able to fingerprint any users who use that exit node as little as once. {...} and check the fingerprint of those requests against big entities like Google, PayPal and banks.
If any of the accesses to a highly illegal source have fairly unique fingerprint that any entity is able to match to a person, you get a court order to search that person's computer for evidence.
(Note: you're answering to the wrong paragraph, I've written about finger printing in the next one).
Yes, but that require a finger-printable browser.
As I've mentioned, the Tor bundle goes to great lenght to make sure that the packaged Tor Browser is as unremarkable as possible.
(Characteristics shared by hundreds of thousands)
Also in the specific case of "high illegal source": if even The Piratebay and Duck Duck Go have .onion addresses (as I've mentioned in my 3rd part), you can bet that the juicy stuff that law enforcement would be aiming (whatever is the current descendant of Silk Road ?) has also an onion address and no exit node will ever see the traffic. There won't be any log to grep.
Palm IIIc was the first to have these characteristics on a PalmOS running device, a whole 7 years before the first iPhone. (Followed shortly by similar specs from Visor)
Psion Series 7 was the first to have them on an EPOC running device, around the same time as Palm, a little bit before Sony Ericsson (same OS).
Though you might argue that the rounded corner on these devices wasn't a design choice, but a limitation to the molded plastic cases (a tiny bit more durable than plastic sharp edges), but the rest : a black screen (actual theme chosen by the user: default was often white, but lots of other colors available, including black), and a colorful grid of apps was there. (Including 3rd party apps, way before Apple even considered starting AppStore).
That's actual hardware being shipped and used back at a time when Apple didn't even had the idea to consider producing phones (having been quite recently been burned by the Newton).
---
Note: Though the Palm IIIc doesn't qualify as smartphone but only a PDA (IrDA only networking. No cell), all the other did support adding a cell modem to expand functionality into what would nowadays be considered as smartphones.
(Visor + their cell modem expansion board is what more or less bootstrapped the whole small slab form factor used by all modern smartphones).
Yes but who did actually lie ?
There might be a very slim chance that these first 150k units sold weren't bought by Snap users, but by Facebook employee asked to buy them so Snap's team would wrongly think that there some existing interest into this crap, order 500k more units produceds and then bankrupt with their unsold stock, enabling the Zuck to finally buy them out.
Sound like bond vilain scheme, but I still believe that there is a tiny chance that this might be true.
The problem with deflector dishes is that the ship is travelling at (say, warp 2, which is four times the speed of light) and the deflector dish puts out a beam which travels faster than that forward of the ship to sweep away all that pesky interstellar dust.
Two things :
- Alcubierre drives, the theoretical physics concept around which the fictional warp drives are based do not actually move the ship.
At all. The ship stays completely immobile in its own frame of reference. (There wouldn't be a way to move it past speed of light anyway).
What you move it the frame of reference it self. You bend the space time it self. You contract it in front of the ship, and expand it behind.
And unlike speed of things which is limited (at C, the speed of light), space-time bending isn't limited
(How the hell to you think our real-world astronomers can observe the distant past by looking at far away points in the space ? if our solar system was just a moving object, it would obligatory move slower than speed of light, and the light emitted in the distant past would have "over-taken" us and would not be observable anymore. The trick is that the space time of our actual universe did expand it self. More space was "created" between the objects, so that now they are further apart, and we can still catch "glimpse" of the beginning of the universe - some of these past images haven't reach us yet, because these image suddenly have way more space to travel to reach us because of that space-time expansion)
The only difference is that Alcubiere drive is a completely theoretical concept. It might not even be doable in the real world : it might happen that distorting the space time this way could require more energy than contain in the universe that you're trying to distort (it took a whole bigbang to expand our universe).
Whereas in Star Trek they just use dilithium crystals or some other fictional stuff in their warp core and can warp around freely.
- Speed of light. :
You're reasoning "the deflector dish puts out a beam which travels faster than that forward of the ship" is based on old classical physics (the speed of some launched from a moving something is the sum of both speeds : a photon launched from a ship travelling near the light speed would it self be launched at nearly twice the lights speed). Classical physics at that speed don't work and give wrong results (there's no such thing as an object moving at twice the light speed).
You're entering the realm of relativist physics
No matter what, the light speed (in vacuum) is constant and the same same every where in all referential. When an object is moving, from the point of view of the object the radiation it's shining forward will travel at exactly 1 C. From your point of view as an observer, the radiation of the deflector will travel at exactly 1 C *too*.
The thing that will change is the time and space. The scales will seems squished and time will seem running slow, so at the end, both the ship and observer will see the same distance/time = speed of light for the radion. The speed of light doesn't change, is the distance and time which end up being different.
There's a bunch of math to compute all this, but then ... (appropriate citation, in Bone's voice) I'm a doctor, Jim ! Not an astrophysicist)
---
(Also not mentioned in your post, but also relevant to the discussion of Star Trek technology : artificial gravity and inertial dampeners.
General relativity.
Which basically states that gravity actually works by playing around with space time too. Except this time, it isn't by expanding or contracting space, but by curving it. Objects aren't actually "attracted" to each other. They simply travel on straight lines (imagine a point travelling on grid on a sheet of paper), but the "straight lines" them selves are curved by the presence of mass (if you draw a sun in the middle of your sheet of paper, the grid suddenly isn't squares anymore but spirals that head towa
It wasn't even good at emulating hardware used by games and creativity programs (music players, graphics stuff etc.)
Depends on the hardware.
If it's some rare custom ISA card hardware : yes it's going to be problematic. (e.g.: some custom ISA controller used by the photo scanner of some graphics creativity program, or a custom ISA multi-channel DAC used by scientific equipment).
If it talks to the computer using a standard way (e.g.: talks over a standard COM port, a MIDI port or - rarely back then - talks over the network using some packet driver) or if the ISA card is a common one (nearly any sound card, including Garvis Ultrasound) : it works pretty well.
That even include emulating some quirks and hacks (TweakMode/ModeX type of graphical modes, abusing the NTSC composite color clash to generate more than the 4 CGA colors, etc.) or even emulating devices connected to the virtual PC (there are software to emulate a full blown MT32 synth connected to the dosbox' MIDI bus).
There's actually atmospheric drag on the ISS such that, without periodic corrections, will drag it down out of orbit. That's true of ANY low earth orbit satellite, of course.
At it's current altitude, the ISS orbit decays about 100m per day. And the lower it dips into the upper atmosphere, the faster the rate of decay becomes. Without correctional boosts, the ISS would probably fall from they sky relatively quickly. I've seen estimations of approximately six months or so.
Which is entirely the point of using that orbit.
Anything else beside the ISS (i.e.: debris) will lack said boost and will eventually fall from the sky rather quickly, which means that such low orbit are relatively clean and only contain the few man-made object that can actually boost and nothing else: this means a lot less risks of debris/micro-meteorite impact and a lot less necessary collision-avoidance corrections.
So basically, instead of mundane Dynamite Blast Fishing, you go Orbital Re-entry Blast Fishing ?
Man that's quite a level of awesomeness.
You can bet that if Microsoft tries to actually seriously implement a log-structured (e.g.: actually decided to use UDF beyond optical and portable flash media) or copy-on-write filesystem (e.g.: ZFS and BTRFS on NT kernels) that supports version control, they'll botch it and there will be an exploit found making the older copies also editable by a non-admin user (the ransomware could purge the older copies and only leave the encrypted version).