...and your grand parents have probably been needing to learn to defend themselves with guns, whereas I (roughly the same age as you) live in a country where I don't even see why the hell I would be needing any weapon. (That's even if I live in one of the few western European nation where it isn't that complicated to legally obtain a gun and corresponding license).
View source is a relic of how the internet used to be. It's not coming back and I would argue should be hidden by default in browsers. It's akin to decompiling the source of an.exe file to look at the code (which some people do) and learn how it does things. Not a good method.
It might come as a surprise to some, but decompiling.exe files to learn was actually a very decent method at some point in the past. Specially at a time (e.g.: older DOS era, speaking of EXE files) when when lots of these software were mostly written in (not too much optimized) assembler.
Decompiler where mostly re-formating the code (indentation), inserting useful comments (regarding the IO-ports used and the parameters passed to software interrupt) thank to some dataflow code tracking, and giving meaningful names to some of the variables and subroutine (if tracking reveals that a sub end-ups being registered as some hardware interrupt handler, "irq_7_audio_handler" is a bettername than "sub_146_i").
Learned quite a few trick back then by doing exactly that (e.g.: kicking the PC speaker into PWM-mode to play digital samples).
Not as good as having the real original code (e.g.: looking how FRACTINT did kick the VGA into Tweaked mode / Mode-X), but still quite useful.
Though much more straight forward than looking at even earlier code (self-modifying code from the heights of 8-bit era, spilling over to some early PC era when programmer got hired there). Or more modern/later code (written in higher level languages then optimized the shitout of by the compiler, or carefully hand-optimized SIMD code), where only the fully commented source could make some sense.
And the web is slowly going into that direction : the ting that the web designer write isn't that much related to the thing that browser sees. they have nice modular tree of numerous JXL object using 3rd party libraries, that will be compiled into a single flat file, then minified (though it's not that much useful in the modern era where everything is compresed on the flight) then obfuscated (that is plain mean).
Nobody writes directy plain HTML, and thus you won't see human readable HTML neither.
Another study that cannot distinguish if it's causation of just correlation.
Actually, it's not the studies' fault. Both studies only use the term "association" (as in : "we found the number to be somewhat correlated") with the first one even in the title. Even in the abstract the second study mentions it's only correlation, and there might even be reverse causation.
But then you can count on the press to spin it up as "Coffee cures death !!!!11!!1!!"
So run Windows in a VM under Ubuntu which is itself a VM under Windows, since the Microsoft Store doesn't replace Windows or even create a separate partition, but just runs Ubuntu in a VM.
No. That's not possible, that's not how Windows Service for Linux (WSL) works. (And that's why, as other have pointed, the link points to the official Ubuntu website to get a full blown real-deal Ubuntu Linux).
WSL isn't a virtual machine. It a different "personnality" of the Windows Kernal, where it speaks a different API than the usual Win32. (the capability dates backs from the earilest WinNT, used to run OS/2 software natively).
WSL enables the Windows kernel to expose a tiny subset of the APIs exposed by the Linux kernel, so some of ubuntu's ELF executable can run natively. (Mostly a few command-line tools). bash.exe is actually just a launcher that start this alternative kernel API. The bash you're seeing is the same actual bash executable as on Ubuntu, but running natively directly on the Windows kernel.
So no, Linux on windows isn't running in a VM, it's windows directly executing the few native linux executable it managed to be compatible with.
Saddly, only a very tiny subset of the Linux API is supported by WSL (stdin/stdout/stderr streams, multi-theading multi-processing, some high level networking (TCP/IP), a 2 special surpose filesystem drivers, and that's about it). None of the various API needed by virtual box are exposed in WSL (no low-level hardware access to kick in the CPU virtualisation (VT-x and co), no graphics access at all, etc.), so you just can start it. So you can't run a Windows VM inside an instances of ubuntu running in WSL. Apache and SSHD are about the most complex task you can get running (that's the whole reason WSL is marketed for : so a web developper can quickly test some server code directly from windows without even needing to start some VM up)
Also, you cannot use the same partition inside VirtualBOX if that's also the same partition the top host of your "piles of VM-turtles all the way down" stack.
You cannot run 2 instances of windows of the same physical media (maybe except if you're running 2 instances of WinPE BootCD of the same CD...) It's NOT linux, it's definitely not as flexible (in Linux this has been possible nearly from the beginning. That's part of the reasoning behind the standard Unix tree (/usr/,...), as long as each instance has its own/var mount. And recent advances in systemd vastly diminish the/var requirements).
Stands a good chance of being better than cygwin anyway.
On some point, it is :
- Cygwin is an attempt for a user-space-level translation layer that provides nearly full POSIX software compatibility while running atop regular Windows. Means it's constricted by whatever the win32 API has to offer. e.g.: multi-threading and specially multi-process in windows suck, Cygwin-compiled unix apps will suck on windows.
- Ubuntu on windows (official name "Windows Service for Linux" - WSL) is using the "multiple-personnallity-disorder" of the Windows kernel. Win32 is just *one* of the API that it can expose. (originally, this was done so OS/2 programs can also run natively under the WinNT kernel simply by also exposing their API as an alternative) (later that was used to provide some Unix-ish API). Microsoft has re-used a failed project to run Android APPs under windows, so that the Windows kernel can provide a small subset of the same APIs as the Linux kernel to run Linux ELFs natively. That means if there's some in-kernel facility that can help supporting Linux software, they can be leveraged even if they are not exposed as a regular Win32 API. e.g.: recent Windows kernels have a concept of very lightweight threads called pico threads that can be used to provide the POSIX-threads to linux applications. Meaning that they have much better performance, than if Cygwin tries to translate to the poor Win32 equivalent.
On the other hands : - Cygwin is about full POSIX compatibility : in theory you should be able to compile any POSIX compilant source and get it to work under Windows. (real world example: GIMP) - though you still need the source. - Windows Service for Linux is about just exposing a tiny subset of the Linux API, just the bare necessary minimum so you can get a few command-line tools running as-is. You can get Apache to run (And that's about one of the few complex software that you can get to run), but not a single API is present to handle graphics so forget about getting GIMP (Unless you use an SSH connection with X forwarding and a Win32 X server). Forget about EXT4/BTRFS/XFS/etc. filesystems (no direct block device access). etc.
Basically : - Cygwin is a translator that converts between Win32 and POSIX API (at the source level) - but some concept maps badly between the two. - Windows Service for Linux is about teaching the Windows kernel, but it only managed to learn a few key sentences.
Argument in the comments between people who claimed they could hear the tones above 16kHz and those who claimed there were no such tones.
16 kHz is close to 15 kHz : that high pitched "mosquitoe" hum that analog TV set, and some un-plugged PC CRT sceen did, and that only some people heard. Not everybody could hear them (age is a factor). That shows you that even if the sound was delivery losslessly, not everybody could hear it.
the OPUS stream contained the original signal descending from 20kHz but all of the AAC streams had artificially chopped off everything above 16kHz.
Considering the above (not everybody is able to hear the 15kHz mosquito hum of an old analog TV set), clamping AAC is a safe bet and a good compromise for compression, probably nobody is going to pay attention to 15 kHz and up frequencies in the middle of a complexe piece of music.
OPUS' clip at 20 kHz is by design. It's designed for human listeners, and we lack any receptor for such high frequency. There's no point in recording and keeping something that could not be heard anyway. If you have a special corner case use where you do need that frequency, don't use a general purpose codec like this (FLAC would be better). (That would be like trying to record the UV and IR light in photographs of your vacations. UV and IR photography is *a thing* in some scientific fields (e.g.: astronomy, medical imaging.), but there's no point in recording it for everyday picture - the eye's len don't let any UV through, and the receptors of the eye don't even react to high energy UV* nor to IR. R/G/B is plenty enough for everyday pictures).
The same way photography is designed for humans and not pistol shrimps/bees/etc. and thus R/G/B is enough, the same way OPUS is designed for humans and not for dogs and thus 20 kHz is enough.
--- *: there's a thin band of near UV that could be picked up by the retina, but would burn and damage the retina, so the len has evolved to block it. Some early-gen cataract replacement artificial lens where transparent at that wavelength, enabling cataract-operation patients to see this tiny bit of UV, at least until they burn their retina. Still it's definitely NOT something you need to record for your vacation pictures. R/G/B will suffice.
Turned out it depended which audio stream Youtube was sending to the listener
And that's a pretty dumb idea (posting your "sound test" on youtube) to begin with. Youtube is designed to share regular music/speech over internet, heavily compressed to make it easier to stream and cheaper to store. Your wierd audio test is guaranteed to hit some unusual corner case and suffer heavily from the compression. What did the uploader expect ?!?
"Hey I'm trying to record bats' calls using an oldschool portable tape recorder and it doesn't work !"
>x86 ISA isn't exactly a lean architecture and instruction set. >Modern ARM can do much better with a small transistor foot print.
In which universe is the ARM instruction set "lean"? Every instruction is 32 bits long, clogging one's instruction bandwidth.
In my universe where the *perfomance* that interests me is the power budget of the IoT device, which is rather closely related to how much the chip maker can cran in as little silicon as possible. the current generation of ARM chips simply provide more with less silicon (among chief reasons : the RISC instruction sets, and the constant instruction width that you've criticized makes the instruction pipeline much simpler) (whereas x86 chips tend to be a RISC-ish backend with a huge x86 interpreter on top of it) (in an over simplified way: ARM just gets rid of the complex instruction decoder, which spares silicon and ends up sparing a few watts which is critical for a IoT device - hence Intel not being king there - whereas nobody give a fuck for a couple of watts on a 200W monster - hence it not being a draw back on high-end desktops and servers).
On the other hand, memory is cheap, flash is cheap too and it doesn't eat that much into the power budget of IoT.
I can only speak for YouTube as I don't use Spotify,
Spotify do the compression themselves from original audio (so there aren't many copy-generational problems).
Spotify uses Vorbis (better quality than MP3 at same bitrate according to A/B test. Definitely better than WMA), because back when they started, that was the best license-free codec guaranteed to be available in the largest set of browsers (it was an IETF standard), and a permissive free library (easy to embed into apps). (This was back before OPUS, the current IETF standard came and basically killed nearly every other codec performance wise - with the sole exception of some extremely low-bandwidth usage that are not found on internet)
Spotify uses bitrates of - 96kbps for its low quality setting (around the same quality as MP3 @~128kbps. So clearly audible, but still largely acceptable quality) - 160kbps for its normal quality settings (very good quality for vorbis, hard to tell appart in most typical settings) -. ~320 for the high quality settings for paying customer for local saves (should sound lossless nearly everywhere).
Spotify has mentionned thinking of adding lossless codecs for local saves (I think it was FLAC ? I'm not sure. But it was recently mentionned on/.) I think they have considered OPUS now that its a IETF standar (like nearly every one else online is doing) (and even the industry is doing informally/experimentally with Digital Radio Mondial).
If you rip the high quality streams from Spotify it means that you have access to an extremely good quality stream (but it also means that you're a paying customer, at which point ripping doesn't make that much sense, as opposed to simply locally saving on the smartphone's SD card with the app and having your music offline everywhere you want it) At least that's for DRM-busting the cache/local saves and for high quality setting. Regular settings are of lower (but still very good) quality.
S/PDIF loop is going to add copy-generationnal loss of whatever you use to re-encode the raw S/PDIF stream (unless you go lossless, e.g.: FLAC).
Analog loop is in practice going to add even more artefacts specially with poor analog connections in an electrically noisy environment (cue in jokes about Apple's shitty audio jacks)
but YouTube vides have MPA audio at 128 kbps at the lower resolutions and 192 kbps at 720p and up. It's arguable, but 128 kbps should be roughly equivalent to 192 kbps MP3. So it's not as bad as you think.
the quality of AAC is *extremely* dependent on the quality of the encoder. See FFMPEG's older codec. (though in this case, it's google. so I would assume that their codec doesn't suck too much).
That's just one of the available codecs on youtube. Youtube will actually generate lots of different formats for each video (that also include completely different codecs), so there is much variability depending on which alternative format one descides to use. e.g. they also provide OPUS @160kbps which is the same kind of "hard to tell appart in A/B/X test" as AAC@192kbps.
But the main problem is in the process itself: Youtube *generates* lots of different formats, from whatever the user has uploaded.
In theory, it's possible to upload an MKV using h264 lossless for video and FLAC for audio (been doing that). But in practice, people will upload whatever the "export" button of their video editor does. Which is very often MP4 file with AAC for the audio. So you have copy-generationnal artifacts due to recoding from one lossy format into another.
Also add to the factor that the AAC codec of the video editor might be crappy. (This is part of the reasons why official youtube recommendations for MP4 and AAC audio are 384 kbps - just to be sure that even crappy codecs manage to make a high enough quality compression).
(Under the command of CEOs who would like to outlaw the huming of copyrighted music)
{...} but I don't exactly think the music artists of large bands are really struggling for money.
The large bands aren't struggling for money anyway and won't feel the impact of piracy much.
The smaller bands are actually under horrendous contracts where they don't actually make that much money anyway. Piracy at least helps getting their music known, and might actually help them getting invited to play in some festivals. Helping them raise on the ladder.
(I don't have a concrete *music* example right of the top of my head, but lots of organisers are watching music popularity trends close to determine up going bands to invite. That also includes watching what happens on the piracy maket. Netflix is a well known *movie* example : they have admitted to also watch piracy popularity to determine which series to license. - there are even articles about this on/. )
They tour because THAT's where they make most of their money.
It used to be that *discs* are where they made money, and concerts were glorified ads campaign for new discs. Currently it's the opposite : there isn't much money in CDs (most of the money end up in the pockets of the label), or streaming, but it helps getting the band known, and then subsequently get invited to play at concerts).
StartTLS is no panacea, an active MITM peer can simply strip the request.
Actually, no. - if you set to StartTLS to "required" (or if you use IMAPS), your client will only go further if a successful SSL/TLS encrypted link is established with the server. The MITM can't just strip the request, the client will refuse to connect. - SSL/TLS links will fail if they are not signed by a recognized authority. The attacker needs to have a key that is signed by a trusted authority (and thus either needs to have a certificate issuer in cahoots - has actually hapenned with some cert authorities in the past - or needs to manage to get control of the e-mail server (thus can actually access without MITM. OR can steel the original private key and freely MITM. OR can generate a new key and have it at least non-EV signed and use this new key for MITM)
MITM is the main class of problems that SSL/TLS can succesfully fight (when done right). (As opposed to "privacy" class of problems, which are better handled with end-to-end encryption, like PGP / GPG (web of trust) or S/MIME (public key/certificates) )
The 386SX? If they just took that design, added some level 1 cache and put it on their current most inexpensive process, they'd be optimal for it.
That would be extremely over-complex. x86 ISA isn't exactly a lean architecture and instruction set. Modern ARM can do much better with a small transistor foot print.
But too bad, Intel discontinued their StrongARM serie.
Why wouldn't a 386 be much of a selling point, when every embedded OS out there - not just Linux or BSD, but also things like FreeDOS, QNX, Minix, Minuet, et al exists for that platform.
The main selling point of a x86 chip would be code compatibility. But nobody sane in their mind is going to try to run Windows XP on a IoT device. All the other OSes are also available on ARM.
The other point where x86 shines is raw performance on high range CPUs (simply because Intel and AMD [x86] are the only company spending R&D money on optimizing chips for that segment. Everybody else - Apple, Qualcom, etc. - are optimizing for the embed market) but that's absolutely NOT what's needed on IoT devices.
If one is looking for flexibility in number of hardware sources, one can limit themselves to Linux & BSD and go look there. If one is looking for flexibility in the choice of OS platforms, then it makes sense to go w/ 386. Only question - is Intel still the only game in town, or does Via or SiS still have their solutions?
That, and writing a non-prototype encoder, most likely.
yup, currently AV-1 is still an alpha.
it's still a playground in which to experiment by activating feature which are currently being developped. (e.g.: the Perceptual Vector Quantization (PVQ) and Assymetic Numeric System entropy coder (ANS) that were developped at Xiph as part of Daala, can be tested into AV-1)
Wait until it hits AV-1, only then will developers start optimizing performance instead of chasing compression factors.
Right ! ARM and Broadcom are on the AOMedia. So if you use some tiny ARM computer board you should be covered (by the time Raspberry Pi 4 or 5 is out, its video-core should be able to handle AV-1).
I use Linux on my home-made quad core desktop.
AMD, Nvidia and Intel are also on board. So probably your future Radeon or Nvidia GPU is going to be able to handle it too.
given that AMD, Nvidia, Intel, ARM, Broadcom are also on board (beside content providers like Netflix, Amazon, Hulu and Google) you can bet that Yes, there are going to be GPU implementations.
(And if you've followed the posts of Xiph - you know that they take GPU into account from the beginning).
Also there are already currently cloud based solution that distribute the compression workload accross a cluster. (Video is split into smaller segment, each segment is independently compressed by a separate job on the cluster, then the compressed streams are concatenated together). And bitmovin is already providing alpha support for AV-1 as it is now (so they can already test their solution and so, in a few months, on the day when AV-1 hits version 1.00 they are already ready and their users have already tested pipelines).
Actually the only single major player that is missing here is Apple. Probably because they are betting all their marbles on their own patended H265/MPEG4 HEVC. They are among the patent owners of the patent - so using/licensing H265 comes much more cheaper for them. Which was the main reason for everybody else to drop H265 and consider joining Aomedia for AV-1 (between the original patent-pool, the other competing pools that have formed with other sets of patents and patent troll waiting to sue to try to get their share, licensing H265 is a much more expensive adventure than licensing H264/MPEG4 AVC was- To the point that H265 licenses cost a significant part of the price of embed ARM SoC as those used by cheap phones, ruining their competitivity)
Most place recommand taking break every 1h30 of driving. After 2h, you definitely need a 30min rest
One of the numerous example of recommendation of making breaks in Europe : french government recommending to take breaks every 2 hours. (France usually has massive campaign against driver tiredness, displayed on the LED screens above highways during holiday breaks, with punny slogans. "Une pause s'impose" is another popular one. And you can count TV and Newspaper to repeat the "2 hours" recommendation). (I've seen similar LED screens campaign in Italy, but I'm not fluent enough to manage to find nice pictures in google image).
(In other words, to go back to the initial thread subject: if you practice the recommended pauses schedule, you'll never run the battery of a Tesla Model 3 (60kWh), Renault Zoe 4.0 (45kWh) or Opel Ampera (60kWh). Just as you won't empty the tank of an ICE either)
And please don't start about driving 8 hours straight with only a single pee br{e}ak in the middle. That's dangerous and borderline illegal (actually is under some circumstance and in some jurisdictions).
Random example : Swiss Law about professional drivers license for regular cars (the kind of driver license one needs to pass when earning money/salary for driving) (i.e.: the kind of license that Uber drivers are required to pass in most cities that actually pay close attention to the law - the few exception are cities who voluntarily accept to close their eyes on UberPop drivers). It's illegal for driver to drive more than 4h30 straight without a 45min break, there are also limits on the total work day (around 7 hours), pauses of 15min or less don't count as pauses.
8h straight with only a pee break is definitely considered illegal for professional drivers in regular cars (= some circumstances) in Switzerland (= some jurisdiction). Similar restrictions for professional drivers exist in most European jurisdictions.
Even if you're not covered by this kind of law, if you are implicated in an accident and it is revealed that you aren't rested enough, you might be considered at fault (the same way if you were intoxicated with an undetermined substance or if less than.05% blood-alcool-level - i.e. situations where there is not a clearly defined legal limit, but you're definitely not able to keep attentive enough anymore). In other words : if the police thinks you're unfit to drive (and there's extensive research on the effects of tiredness on driving, and statistics on its implication in accidents), you're at fault, even if the law doesn't state precise numbers (sleep, some drugs) or you're under the numbers (.049% BAL, when the limit is.05%). In short: even when it's not explicitly stated in law, you're definitely in for some troubles.
My wife is from Asia and most banks there (as well as in Europe it seems?) require 2FA systems like challenge response and customers have zero problems with it. My wife's bank provides her with a card has challenge-response codes that she has to use when she logs in.
European here.
Most banks have moved beyond pre-printed cards for more security. Now users are issued a PKI card (a physical one with a dedicated pocket-calculator-like terminal. Or one with electronics directly on the card. Or a virtual one in smartphone app).
To log, and to confirm security points, the user is asked to sign some pieces of data. (Either typing it on the terminal or on the built-in electronic. Or even using some optical exchange with the screen (barcodes, qr-codes) and confirming it on the device/app display).
i.e.: the transmission could be completely MitM-ed and you still get secure transaction thank to the 2FA. (e.g.: the signature that your terminal or app generate are for the account number you intend to send money to. Even if an MitM attacker change acount number behind the scene (you ask to send money to acount AbC, but attacker re-forges the request to the bank to send money to their own account XyZ instead), the security token you send (or the security message you get on the screen) won't match the forged account number, but the original one.
How do you want to motivate kids in such an environment to waste their time on learning anything? It's moot anyway. And I can't blame them, they're mostly even right.
And the next generation after that, will be Appy App Appers, that will try to get rich by writing the best and most successful Appy App on the AppStore, and become Appillionaires.
(Hey! Where's the "App" Troll when you need him ?)
Rates of genetic disease are also much higher with older dads,
[Citation needed] - it does interest me : I've never seen such information before.
Also, unlike ovocytes which are stored longterm from birth onward (and thus can over time accumulate damage - even if they have mecanism to try to avoid it. That's also why women experience menopause once they run out of ovocytes), spermatozoon are constantly produced over the lifetime, they are all relatively fresh cells and are thus a little bit less likely to suffer from environmental damage (environmental toxic substance could still cause damage to the gonia cell producing them, but at least they are not siting cold, exposed to risks). Thus I would expect that, for physic-chemical reasons, dad's age is a tiny bit less impacting than mom.
and the father being 40 or older is the main known risk factor for autism.
In addition to criticism behind the "main" part of this sentence as mentioned by other in this thread, I would add criticism to the "risk factor".
The same mantra as usual goes : "correlation doesn't necessarily means causation". There might be a mechanism (like the defect accumulated over time in dad's cell - albeit at a lower rate than mom's - could by random chance be a mutation that influence autism). But there might also be a confounding factor (an independent factor that cause both of the observed manifestation) And here there's clearly a well known one : high intellect. - high intellect sometime borders on autistic spectrum, the same kind of gene that can influence a high IQ (attention to detail) might also push over to the pathology. (See studies about higher rate of autism in some regions like silicon valley). - also these parents tend to do long academic studies and/or carrier, and thus tend to reproduce later in their life.
Oh, then that's what Covfefe was ! That's why "The president and a small group of people know exactly what he meant [by covfefe]" ! It was a super secret code word to fix a vulnerability in Microsoft Windows before the Petya ransomware spreads ?
Most companies like GoG use DosBox for the purpose of distributing DOS based games with however.
DOSBox is an *emulator* (like VirtualBox and VMWare). It provide some minimalist subset of DOS (like the above mentionned provide their own BIOS and/or EFI implementation). But that's far from a full MS-DOS compatible environment. If you need anything DOSBOX's bare minimum (which is essentially just a minimalistic shell) you need FreeDOS (e.g.: MORE command)
For games that don't immediately take over the hardware and control it with BIOS calls and straight IO ports banging (i.e.: anything that uses a complicated.BAT launcher), you'll need extra parts and Free DOS is a nice source for you to get them.
(So DOSBox should be compared to FreeDOS, but instead to FreeDOS' kernel and a few critical.SYS)
Tesla cars are expensive bling, but this doesn't meet the needs of most people.
Depends on where those people are. Europe being more densely populated, its actually exactly the king of thing people need. Which explains the success of other cars with similar characteristics have been having during the past few years. (e.g.: Renault's Zoe, Citroen C-zero, etc.)
Lots of people travel 20 or 30 miles to and from work. However, we also have errands and other things to do.
Which all fall well within ~340km / 215 miles range of the car.
Many of us also travel on weekends and make trips a few times per year. The short range of these vehicles {....}
Which taking into account the highway speed limitations in Europe (between 120 and 130 depending on countries - with the exception of Germany having some limit-less sections), means that the car can travel without any problem for 2 hours on a single charge (you could push it closer to 3h if you don't drive like an asshole) (actual experience driving various electric cars).
Which means that this car can reach as far as you can before you need to take break. (Most place recommand taking break every 1h30 of driving. After 2h, you definitely need a 30min rest - by which time batteries could be fully charged again by a supercharger). And please don't start about driving 8 hours straigh with only a single pee brak in the middle. That's dangerous and borderline illegal (actually is under some circumstance and in some jurisdictions).
coupled with the significant recharge time
on normal week days, the car slowly charges over night so you don't give a damn about it. on trip, a supercharger can fill the battery in about half an hour which okay as you need to take a break as a driver, otherwise you are a risk on the road.
lack of available charging stations in some areas
Tesla has a nice network of charging station in Europe.
European models of Tesla also use a Mennekes connector like everybody else (unlike the weird shit US models use) meanning that you can charge a Tesla on the numerous charging station that are popping everywhere. (Though not at full speed like on a super charger. Tesla lack the 2 extra pins of "combo" chargers and thus can only charge using AC at regular station. Though I've hread that Telsa is producing adapter (at least ChaDeMo) so it would be possible to charge faster with it). But it basically means you can also charge while doing your groceries, etc.
But congratulations on making a car that people will probably buy even though it doesn't meet their needs.
don't get me started with US' obesssion with SUVs.
Elon Musk is even better at convincing people to buy overpriced junk than Steve Jobs was.
It's not over priced, it's the regular price of a car once you factor in the price of the battery. Compare it, specially with Zoes (Renault sells them both with battery included, and with a separate battery rental - you only pay the car without the batteries).
-I wish iOS had an advanced mode you could enable.
You mean like Palm/HP webOS's developer mode ? (type in the command "webOS2009060" in universal seach. Or for shit and giggles, you can also spell out literally the Konami code "upupdowndownleftrightleftrightbastart", but it's a bit longer to type) (Also the default remote-shell is a bit shitty ("novacom" - some adb-like thingy) buy you can install openssh)
You mean like Jolla Sailfish OS developer mode ? (check in the "developer mode" box in the settings, it will even automatically download ssh for you).
You mean like several android tablet that allow fastboot unlocking ? (again adb shell sucks, but I hear that drop bear is installable)
You mean like the ancient OpenMoko FreeRunner (most system image come with ssh preinstalled)
You mean like most other full GNU/Linux running phone ?
Slashdot Mirror
...and your grand parents have probably been needing to learn to defend themselves with guns, whereas I (roughly the same age as you) live in a country where I don't even see why the hell I would be needing any weapon.
(That's even if I live in one of the few western European nation where it isn't that complicated to legally obtain a gun and corresponding license).
Pretentiously so, IMHO.
Come on. Not everything needs to be Turing-Complete.
(as PostScript, PDF and C++'s templating engine are).
View source is a relic of how the internet used to be. It's not coming back and I would argue should be hidden by default in browsers. It's akin to decompiling the source of an .exe file to look at the code (which some people do) and learn how it does things. Not a good method.
It might come as a surprise to some, but decompiling .exe files to learn was actually a very decent method at some point in the past.
Specially at a time (e.g.: older DOS era, speaking of EXE files) when when lots of these software were mostly written in (not too much optimized) assembler.
Decompiler where mostly re-formating the code (indentation), inserting useful comments (regarding the IO-ports used and the parameters passed to software interrupt) thank to some dataflow code tracking, and giving meaningful names to some of the variables and subroutine (if tracking reveals that a sub end-ups being registered as some hardware interrupt handler, "irq_7_audio_handler" is a bettername than "sub_146_i").
Learned quite a few trick back then by doing exactly that (e.g.: kicking the PC speaker into PWM-mode to play digital samples).
Not as good as having the real original code (e.g.: looking how FRACTINT did kick the VGA into Tweaked mode / Mode-X), but still quite useful.
Though much more straight forward than looking at even earlier code (self-modifying code from the heights of 8-bit era, spilling over to some early PC era when programmer got hired there).
Or more modern/later code (written in higher level languages then optimized the shitout of by the compiler, or carefully hand-optimized SIMD code), where only the fully commented source could make some sense.
And the web is slowly going into that direction :
the ting that the web designer write isn't that much related to the thing that browser sees.
they have nice modular tree of numerous JXL object using 3rd party libraries, that will be compiled into a single flat file,
then minified (though it's not that much useful in the modern era where everything is compresed on the flight)
then obfuscated (that is plain mean).
Nobody writes directy plain HTML,
and thus you won't see human readable HTML neither.
Another study that cannot distinguish if it's causation of just correlation.
Actually, it's not the studies' fault.
Both studies only use the term "association" (as in : "we found the number to be somewhat correlated") with the first one even in the title.
Even in the abstract the second study mentions it's only correlation, and there might even be reverse causation.
But then you can count on the press to spin it up as "Coffee cures death !!!!11!!1!!"
Ob. PHDcomics ref
Starbucks sells coffee now?
Yeah, it's one of their flavour that you can ask on your pumpkin syrup.
So run Windows in a VM under Ubuntu which is itself a VM under Windows, since the Microsoft Store doesn't replace Windows or even create a separate partition, but just runs Ubuntu in a VM.
No. That's not possible, that's not how Windows Service for Linux (WSL) works.
(And that's why, as other have pointed, the link points to the official Ubuntu website to get a full blown real-deal Ubuntu Linux).
WSL isn't a virtual machine.
It a different "personnality" of the Windows Kernal, where it speaks a different API than the usual Win32.
(the capability dates backs from the earilest WinNT, used to run OS/2 software natively).
WSL enables the Windows kernel to expose a tiny subset of the APIs exposed by the Linux kernel, so some of ubuntu's ELF executable can run natively. (Mostly a few command-line tools).
bash.exe is actually just a launcher that start this alternative kernel API.
The bash you're seeing is the same actual bash executable as on Ubuntu, but running natively directly on the Windows kernel.
So no, Linux on windows isn't running in a VM, it's windows directly executing the few native linux executable it managed to be compatible with.
Saddly, only a very tiny subset of the Linux API is supported by WSL (stdin/stdout/stderr streams, multi-theading multi-processing, some high level networking (TCP/IP), a 2 special surpose filesystem drivers, and that's about it).
None of the various API needed by virtual box are exposed in WSL (no low-level hardware access to kick in the CPU virtualisation (VT-x and co), no graphics access at all, etc.), so you just can start it.
So you can't run a Windows VM inside an instances of ubuntu running in WSL.
Apache and SSHD are about the most complex task you can get running (that's the whole reason WSL is marketed for : so a web developper can quickly test some server code directly from windows without even needing to start some VM up)
Also, you cannot use the same partition inside VirtualBOX if that's also the same partition the top host of your "piles of VM-turtles all the way down" stack.
You cannot run 2 instances of windows of the same physical media (maybe except if you're running 2 instances of WinPE BootCD of the same CD...) ...), as long as each instance has its own /var mount. And recent advances in systemd vastly diminish the /var requirements).
It's NOT linux, it's definitely not as flexible (in Linux this has been possible nearly from the beginning. That's part of the reasoning behind the standard Unix tree (/usr/,
Stands a good chance of being better than cygwin anyway.
On some point, it is :
- Cygwin is an attempt for a user-space-level translation layer that provides nearly full POSIX software compatibility while running atop regular Windows.
Means it's constricted by whatever the win32 API has to offer.
e.g.: multi-threading and specially multi-process in windows suck, Cygwin-compiled unix apps will suck on windows.
- Ubuntu on windows (official name "Windows Service for Linux" - WSL) is using the "multiple-personnallity-disorder" of the Windows kernel.
Win32 is just *one* of the API that it can expose. (originally, this was done so OS/2 programs can also run natively under the WinNT kernel simply by also exposing their API as an alternative) (later that was used to provide some Unix-ish API).
Microsoft has re-used a failed project to run Android APPs under windows, so that the Windows kernel can provide a small subset of the same APIs as the Linux kernel to run Linux ELFs natively. That means if there's some in-kernel facility that can help supporting Linux software, they can be leveraged even if they are not exposed as a regular Win32 API.
e.g.: recent Windows kernels have a concept of very lightweight threads called pico threads that can be used to provide the POSIX-threads to linux applications. Meaning that they have much better performance, than if Cygwin tries to translate to the poor Win32 equivalent.
On the other hands :
- Cygwin is about full POSIX compatibility : in theory you should be able to compile any POSIX compilant source and get it to work under Windows.
(real world example: GIMP) - though you still need the source.
- Windows Service for Linux is about just exposing a tiny subset of the Linux API, just the bare necessary minimum so you can get a few command-line tools running as-is.
You can get Apache to run (And that's about one of the few complex software that you can get to run), but not a single API is present to handle graphics so forget about getting GIMP (Unless you use an SSH connection with X forwarding and a Win32 X server).
Forget about EXT4/BTRFS/XFS/etc. filesystems (no direct block device access).
etc.
Basically :
- Cygwin is a translator that converts between Win32 and POSIX API (at the source level) - but some concept maps badly between the two.
- Windows Service for Linux is about teaching the Windows kernel, but it only managed to learn a few key sentences.
Speaking of which
Argument in the comments between people who claimed they could hear the tones above 16kHz and those who claimed there were no such tones.
16 kHz is close to 15 kHz : that high pitched "mosquitoe" hum that analog TV set, and some un-plugged PC CRT sceen did, and that only some people heard.
Not everybody could hear them (age is a factor).
That shows you that even if the sound was delivery losslessly, not everybody could hear it.
the OPUS stream contained the original signal descending from 20kHz but all of the AAC streams had artificially chopped off everything above 16kHz.
Considering the above (not everybody is able to hear the 15kHz mosquito hum of an old analog TV set), clamping AAC is a safe bet and a good compromise for compression, probably nobody is going to pay attention to 15 kHz and up frequencies in the middle of a complexe piece of music.
OPUS' clip at 20 kHz is by design. It's designed for human listeners, and we lack any receptor for such high frequency. There's no point in recording and keeping something that could not be heard anyway. If you have a special corner case use where you do need that frequency, don't use a general purpose codec like this (FLAC would be better).
(That would be like trying to record the UV and IR light in photographs of your vacations.
UV and IR photography is *a thing* in some scientific fields (e.g.: astronomy, medical imaging.), but there's no point in recording it for everyday picture - the eye's len don't let any UV through, and the receptors of the eye don't even react to high energy UV* nor to IR. R/G/B is plenty enough for everyday pictures).
The same way photography is designed for humans and not pistol shrimps/bees/etc. and thus R/G/B is enough,
the same way OPUS is designed for humans and not for dogs and thus 20 kHz is enough.
---
*: there's a thin band of near UV that could be picked up by the retina, but would burn and damage the retina, so the len has evolved to block it.
Some early-gen cataract replacement artificial lens where transparent at that wavelength, enabling cataract-operation patients to see this tiny bit of UV, at least until they burn their retina.
Still it's definitely NOT something you need to record for your vacation pictures. R/G/B will suffice.
Turned out it depended which audio stream Youtube was sending to the listener
And that's a pretty dumb idea (posting your "sound test" on youtube) to begin with.
Youtube is designed to share regular music/speech over internet, heavily compressed to make it easier to stream and cheaper to store.
Your wierd audio test is guaranteed to hit some unusual corner case and suffer heavily from the compression.
What did the uploader expect ?!?
"Hey I'm trying to record bats' calls using an oldschool portable tape recorder and it doesn't work !"
>x86 ISA isn't exactly a lean architecture and instruction set.
>Modern ARM can do much better with a small transistor foot print.
In which universe is the ARM instruction set "lean"?
Every instruction is 32 bits long, clogging one's instruction bandwidth.
In my universe where the *perfomance* that interests me is the power budget of the IoT device, which is rather closely related to how much the chip maker can cran in as little silicon as possible. the current generation of ARM chips simply provide more with less silicon (among chief reasons : the RISC instruction sets, and the constant instruction width that you've criticized makes the instruction pipeline much simpler) (whereas x86 chips tend to be a RISC-ish backend with a huge x86 interpreter on top of it) (in an over simplified way: ARM just gets rid of the complex instruction decoder, which spares silicon and ends up sparing a few watts which is critical for a IoT device - hence Intel not being king there - whereas nobody give a fuck for a couple of watts on a 200W monster - hence it not being a draw back on high-end desktops and servers).
On the other hand, memory is cheap, flash is cheap too and it doesn't eat that much into the power budget of IoT.
I can only speak for YouTube as I don't use Spotify,
Spotify do the compression themselves from original audio (so there aren't many copy-generational problems).
Spotify uses Vorbis (better quality than MP3 at same bitrate according to A/B test. Definitely better than WMA), because back when they started, that was the best license-free codec guaranteed to be available in the largest set of browsers (it was an IETF standard), and a permissive free library (easy to embed into apps).
(This was back before OPUS, the current IETF standard came and basically killed nearly every other codec performance wise - with the sole exception of some extremely low-bandwidth usage that are not found on internet)
Spotify uses bitrates of
- 96kbps for its low quality setting (around the same quality as MP3 @~128kbps. So clearly audible, but still largely acceptable quality)
- 160kbps for its normal quality settings (very good quality for vorbis, hard to tell appart in most typical settings)
-. ~320 for the high quality settings for paying customer for local saves (should sound lossless nearly everywhere).
Spotify has mentionned thinking of adding lossless codecs for local saves (I think it was FLAC ? I'm not sure. But it was recently mentionned on /.)
I think they have considered OPUS now that its a IETF standar (like nearly every one else online is doing) (and even the industry is doing informally/experimentally with Digital Radio Mondial).
If you rip the high quality streams from Spotify it means that you have access to an extremely good quality stream (but it also means that you're a paying customer, at which point ripping doesn't make that much sense, as opposed to simply locally saving on the smartphone's SD card with the app and having your music offline everywhere you want it)
At least that's for DRM-busting the cache/local saves and for high quality setting.
Regular settings are of lower (but still very good) quality.
S/PDIF loop is going to add copy-generationnal loss of whatever you use to re-encode the raw S/PDIF stream (unless you go lossless, e.g.: FLAC).
Analog loop is in practice going to add even more artefacts specially with poor analog connections in an electrically noisy environment (cue in jokes about Apple's shitty audio jacks)
but YouTube vides have MPA audio at 128 kbps at the lower resolutions and 192 kbps at 720p and up. It's arguable, but 128 kbps should be roughly equivalent to 192 kbps MP3. So it's not as bad as you think.
the quality of AAC is *extremely* dependent on the quality of the encoder. See FFMPEG's older codec. (though in this case, it's google. so I would assume that their codec doesn't suck too much).
That's just one of the available codecs on youtube. Youtube will actually generate lots of different formats for each video (that also include completely different codecs), so there is much variability depending on which alternative format one descides to use. e.g. they also provide OPUS @160kbps which is the same kind of "hard to tell appart in A/B/X test" as AAC@192kbps.
But the main problem is in the process itself :
Youtube *generates* lots of different formats, from whatever the user has uploaded.
In theory, it's possible to upload an MKV using h264 lossless for video and FLAC for audio (been doing that).
But in practice, people will upload whatever the "export" button of their video editor does.
Which is very often MP4 file with AAC for the audio.
So you have copy-generationnal artifacts due to recoding from one lossy format into another.
Also add to the factor that the AAC codec of the video editor might be crappy.
(This is part of the reasons why official youtube recommendations for MP4 and AAC audio are 384 kbps - just to be sure that even crappy codecs manage to make a high enough quality compression).
So that 192 kbps AAC audio you get on
In reality, stream ripping isn't really much different to copying to cassette from the radio like everyone was doing in the 80's.
"But *this time around*, home taping will be killing the music. For sure. Honest !"
-- brought to you by the industry that keep crying "wolf".
(Under the command of CEOs who would like to outlaw the huming of copyrighted music)
{...} but I don't exactly think the music artists of large bands are really struggling for money.
The large bands aren't struggling for money anyway and won't feel the impact of piracy much.
The smaller bands are actually under horrendous contracts where they don't actually make that much money anyway. Piracy at least helps getting their music known, and might actually help them getting invited to play in some festivals. Helping them raise on the ladder.
(I don't have a concrete *music* example right of the top of my head, but lots of organisers are watching music popularity trends close to determine up going bands to invite. That also includes watching what happens on the piracy maket. /. )
Netflix is a well known *movie* example : they have admitted to also watch piracy popularity to determine which series to license. - there are even articles about this on
They tour because THAT's where they make most of their money.
It used to be that *discs* are where they made money, and concerts were glorified ads campaign for new discs.
Currently it's the opposite : there isn't much money in CDs (most of the money end up in the pockets of the label), or streaming, but it helps getting the band known, and then subsequently get invited to play at concerts).
StartTLS is no panacea, an active MITM peer can simply strip the request.
Actually, no.
- if you set to StartTLS to "required" (or if you use IMAPS), your client will only go further if a successful SSL/TLS encrypted link is established with the server.
The MITM can't just strip the request, the client will refuse to connect.
- SSL/TLS links will fail if they are not signed by a recognized authority.
The attacker needs to have a key that is signed by a trusted authority (and thus either needs to have a certificate issuer in cahoots - has actually hapenned with some cert authorities in the past - or needs to manage to get control of the e-mail server (thus can actually access without MITM. OR can steel the original private key and freely MITM. OR can generate a new key and have it at least non-EV signed and use this new key for MITM)
MITM is the main class of problems that SSL/TLS can succesfully fight (when done right). /certificates) )
(As opposed to "privacy" class of problems, which are better handled with end-to-end encryption, like PGP / GPG (web of trust) or S/MIME (public key
The 386SX? If they just took that design, added some level 1 cache and put it on their current most inexpensive process, they'd be optimal for it.
That would be extremely over-complex.
x86 ISA isn't exactly a lean architecture and instruction set.
Modern ARM can do much better with a small transistor foot print.
But too bad, Intel discontinued their StrongARM serie.
Why wouldn't a 386 be much of a selling point, when every embedded OS out there - not just Linux or BSD, but also things like FreeDOS, QNX, Minix, Minuet, et al exists for that platform.
The main selling point of a x86 chip would be code compatibility.
But nobody sane in their mind is going to try to run Windows XP on a IoT device.
All the other OSes are also available on ARM.
The other point where x86 shines is raw performance on high range CPUs (simply because Intel and AMD [x86] are the only company spending R&D money on optimizing chips for that segment. Everybody else - Apple, Qualcom, etc. - are optimizing for the embed market)
but that's absolutely NOT what's needed on IoT devices.
If one is looking for flexibility in number of hardware sources, one can limit themselves to Linux & BSD and go look there. If one is looking for flexibility in the choice of OS platforms, then it makes sense to go w/ 386. Only question - is Intel still the only game in town, or does Via or SiS still have their solutions?
That, and writing a non-prototype encoder, most likely.
yup, currently AV-1 is still an alpha.
it's still a playground in which to experiment by activating feature which are currently being developped.
(e.g.: the Perceptual Vector Quantization (PVQ) and Assymetic Numeric System entropy coder (ANS) that were developped at Xiph as part of Daala, can be tested into AV-1)
Wait until it hits AV-1, only then will developers start optimizing performance instead of chasing compression factors.
This should come to Kodi, right?
Right !
ARM and Broadcom are on the AOMedia.
So if you use some tiny ARM computer board you should be covered (by the time Raspberry Pi 4 or 5 is out, its video-core should be able to handle AV-1).
I use Linux on my home-made quad core desktop.
AMD, Nvidia and Intel are also on board.
So probably your future Radeon or Nvidia GPU is going to be able to handle it too.
I wonder if GPUs can speed things up?
given that AMD, Nvidia, Intel, ARM, Broadcom are also on board (beside content providers like Netflix, Amazon, Hulu and Google)
you can bet that Yes, there are going to be GPU implementations.
(And if you've followed the posts of Xiph - you know that they take GPU into account from the beginning).
Also there are already currently cloud based solution that distribute the compression workload accross a cluster.
(Video is split into smaller segment, each segment is independently compressed by a separate job on the cluster, then the compressed streams are concatenated together).
And bitmovin is already providing alpha support for AV-1 as it is now (so they can already test their solution and so, in a few months, on the day when AV-1 hits version 1.00 they are already ready and their users have already tested pipelines).
Actually the only single major player that is missing here is Apple.
Probably because they are betting all their marbles on their own patended H265/MPEG4 HEVC.
They are among the patent owners of the patent - so using/licensing H265 comes much more cheaper for them.
Which was the main reason for everybody else to drop H265 and consider joining Aomedia for AV-1 (between the original patent-pool, the other competing pools that have formed with other sets of patents and patent troll waiting to sue to try to get their share, licensing H265 is a much more expensive adventure than licensing H264/MPEG4 AVC was- To the point that H265 licenses cost a significant part of the price of embed ARM SoC as those used by cheap phones, ruining their competitivity)
Citations needed
Citations provided:
Most place recommand taking break every 1h30 of driving. After 2h, you definitely need a 30min rest
One of the numerous example of recommendation of making breaks in Europe :
french government recommending to take breaks every 2 hours.
(France usually has massive campaign against driver tiredness, displayed on the LED screens above highways during holiday breaks, with punny slogans. "Une pause s'impose" is another popular one. And you can count TV and Newspaper to repeat the "2 hours" recommendation).
(I've seen similar LED screens campaign in Italy, but I'm not fluent enough to manage to find nice pictures in google image).
(In other words, to go back to the initial thread subject: if you practice the recommended pauses schedule, you'll never run the battery of a Tesla Model 3 (60kWh), Renault Zoe 4.0 (45kWh) or Opel Ampera (60kWh).
Just as you won't empty the tank of an ICE either)
And please don't start about driving 8 hours straight with only a single pee br{e}ak in the middle. That's dangerous and borderline illegal (actually is under some circumstance and in some jurisdictions).
Random example :
Swiss Law about professional drivers license for regular cars (the kind of driver license one needs to pass when earning money/salary for driving) (i.e.: the kind of license that Uber drivers are required to pass in most cities that actually pay close attention to the law - the few exception are cities who voluntarily accept to close their eyes on UberPop drivers).
It's illegal for driver to drive more than 4h30 straight without a 45min break, there are also limits on the total work day (around 7 hours), pauses of 15min or less don't count as pauses.
8h straight with only a pee break is definitely considered illegal for professional drivers in regular cars (= some circumstances) in Switzerland (= some jurisdiction).
Similar restrictions for professional drivers exist in most European jurisdictions.
Even if you're not covered by this kind of law, if you are implicated in an accident and it is revealed that you aren't rested enough, you might be considered at fault (the same way if you were intoxicated with an undetermined substance or if less than .05% blood-alcool-level - i.e. situations where there is not a clearly defined legal limit, but you're definitely not able to keep attentive enough anymore). .05%).
In other words : if the police thinks you're unfit to drive (and there's extensive research on the effects of tiredness on driving, and statistics on its implication in accidents), you're at fault, even if the law doesn't state precise numbers (sleep, some drugs) or you're under the numbers (.049% BAL, when the limit is
In short: even when it's not explicitly stated in law, you're definitely in for some troubles.
My wife is from Asia and most banks there (as well as in Europe it seems?) require 2FA systems like challenge response and customers have zero problems with it. My wife's bank provides her with a card has challenge-response codes that she has to use when she logs in.
European here.
Most banks have moved beyond pre-printed cards for more security.
Now users are issued a PKI card (a physical one with a dedicated pocket-calculator-like terminal. Or one with electronics directly on the card. Or a virtual one in smartphone app).
To log, and to confirm security points, the user is asked to sign some pieces of data.
(Either typing it on the terminal or on the built-in electronic.
Or even using some optical exchange with the screen (barcodes, qr-codes) and confirming it on the device/app display).
i.e.: the transmission could be completely MitM-ed and you still get secure transaction thank to the 2FA.
(e.g.: the signature that your terminal or app generate are for the account number you intend to send money to.
Even if an MitM attacker change acount number behind the scene (you ask to send money to acount AbC, but attacker re-forges the request to the bank to send money to their own account XyZ instead), the security token you send (or the security message you get on the screen) won't match the forged account number, but the original one.
How do you want to motivate kids in such an environment to waste their time on learning anything? It's moot anyway. And I can't blame them, they're mostly even right.
And the next generation after that, will be Appy App Appers, that will try to get rich by writing the best and most successful Appy App on the AppStore, and become Appillionaires.
(Hey! Where's the "App" Troll when you need him ?)
Rates of genetic disease are also much higher with older dads,
[Citation needed] - it does interest me : I've never seen such information before.
Also, unlike ovocytes which are stored longterm from birth onward (and thus can over time accumulate damage - even if they have mecanism to try to avoid it. That's also why women experience menopause once they run out of ovocytes), spermatozoon are constantly produced over the lifetime, they are all relatively fresh cells and are thus a little bit less likely to suffer from environmental damage (environmental toxic substance could still cause damage to the gonia cell producing them, but at least they are not siting cold, exposed to risks).
Thus I would expect that, for physic-chemical reasons, dad's age is a tiny bit less impacting than mom.
and the father being 40 or older is the main known risk factor for autism.
In addition to criticism behind the "main" part of this sentence as mentioned by other in this thread,
I would add criticism to the "risk factor".
The same mantra as usual goes : " correlation doesn't necessarily means causation ".
There might be a mechanism (like the defect accumulated over time in dad's cell - albeit at a lower rate than mom's - could by random chance be a mutation that influence autism).
But there might also be a confounding factor (an independent factor that cause both of the observed manifestation)
And here there's clearly a well known one : high intellect.
- high intellect sometime borders on autistic spectrum, the same kind of gene that can influence a high IQ (attention to detail) might also push over to the pathology. (See studies about higher rate of autism in some regions like silicon valley).
- also these parents tend to do long academic studies and/or carrier, and thus tend to reproduce later in their life.
Or, like me at 40, organized crime.
Private sector or government ?
he will tweet a 3am patch for the backdoors
Oh, then that's what Covfefe was !
That's why "The president and a small group of people know exactly what he meant [by covfefe]" !
It was a super secret code word to fix a vulnerability in Microsoft Windows before the Petya ransomware spreads ?
Most companies like GoG use DosBox for the purpose of distributing DOS based games with however.
DOSBox is an *emulator* (like VirtualBox and VMWare).
It provide some minimalist subset of DOS (like the above mentionned provide their own BIOS and/or EFI implementation).
But that's far from a full MS-DOS compatible environment. If you need anything DOSBOX's bare minimum (which is essentially just a minimalistic shell) you need FreeDOS (e.g.: MORE command)
For games that don't immediately take over the hardware and control it with BIOS calls and straight IO ports banging (i.e.: anything that uses a complicated .BAT launcher), you'll need extra parts and Free DOS is a nice source for you to get them.
(So DOSBox should be compared to FreeDOS, but instead to FreeDOS' kernel and a few critical .SYS)
Tesla cars are expensive bling, but this doesn't meet the needs of most people.
Depends on where those people are.
Europe being more densely populated, its actually exactly the king of thing people need.
Which explains the success of other cars with similar characteristics have been having during the past few years.
(e.g.: Renault's Zoe, Citroen C-zero, etc.)
Lots of people travel 20 or 30 miles to and from work. However, we also have errands and other things to do.
Which all fall well within ~340km / 215 miles range of the car.
Many of us also travel on weekends and make trips a few times per year. The short range of these vehicles {....}
Which taking into account the highway speed limitations in Europe (between 120 and 130 depending on countries - with the exception of Germany having some limit-less sections), means that the car can travel without any problem for 2 hours on a single charge (you could push it closer to 3h if you don't drive like an asshole) (actual experience driving various electric cars).
Which means that this car can reach as far as you can before you need to take break. (Most place recommand taking break every 1h30 of driving. After 2h, you definitely need a 30min rest - by which time batteries could be fully charged again by a supercharger).
And please don't start about driving 8 hours straigh with only a single pee brak in the middle. That's dangerous and borderline illegal (actually is under some circumstance and in some jurisdictions).
coupled with the significant recharge time
on normal week days, the car slowly charges over night so you don't give a damn about it.
on trip, a supercharger can fill the battery in about half an hour which okay as you need to take a break as a driver, otherwise you are a risk on the road.
lack of available charging stations in some areas
Tesla has a nice network of charging station in Europe.
European models of Tesla also use a Mennekes connector like everybody else (unlike the weird shit US models use) meanning that you can charge a Tesla on the numerous charging station that are popping everywhere.
(Though not at full speed like on a super charger. Tesla lack the 2 extra pins of "combo" chargers and thus can only charge using AC at regular station. Though I've hread that Telsa is producing adapter (at least ChaDeMo) so it would be possible to charge faster with it).
But it basically means you can also charge while doing your groceries, etc.
But congratulations on making a car that people will probably buy even though it doesn't meet their needs.
don't get me started with US' obesssion with SUVs.
Elon Musk is even better at convincing people to buy overpriced junk than Steve Jobs was.
It's not over priced, it's the regular price of a car once you factor in the price of the battery.
Compare it, specially with Zoes (Renault sells them both with battery included, and with a separate battery rental - you only pay the car without the batteries).
-I wish iOS had an advanced mode you could enable.
You mean like Palm/HP webOS's developer mode ? (type in the command "webOS2009060" in universal seach. Or for shit and giggles, you can also spell out literally the Konami code "upupdowndownleftrightleftrightbastart", but it's a bit longer to type) (Also the default remote-shell is a bit shitty ("novacom" - some adb-like thingy) buy you can install openssh)
You mean like Jolla Sailfish OS developer mode ? (check in the "developer mode" box in the settings, it will even automatically download ssh for you).
You mean like several android tablet that allow fastboot unlocking ? (again adb shell sucks, but I hear that drop bear is installable)
You mean like the ancient OpenMoko FreeRunner (most system image come with ssh preinstalled)
You mean like most other full GNU/Linux running phone ?
Yep. Apple is the definite oddball here.