Last time I checked JavaScript was transferred in character format, not binary
You can send it as binary - use HTTP compression. I believe most webservers support it as do webbrowsers, so the javascript file is compressed and the compressed binary is sent over the wires, and the web browser will decompress the blob back to the original javascript.
Wanta drive, kid? Show how much you want it by learning how or take public transportation.
The problem is needing to drive in the first place.
In places with good public transportation (e.g., Europe), you don't need to drive - you can get around pretty damn effectively with just public transportation. Hell, you can even get between cities taking the trains and planes and never needing to step in a car.
Problem is, then you go to places like North America, where the vast majority of cities are car-only. Walking only gets you from one big box store to another (assuming you can cross that 10 lane highway in-between them), and public transit is non-existent. There you less WANT to drive but instead NEED to drive.
Driving's a chore. It's something most drivers in North America don't want to do (as evidenced by their attention being held elsewhere, typically on small handheld devices). What needs to be done is eliminating the need to drive, so those who drive are those that want to.
The lawyers get paid, the company gets indemnified from future lawsuits, the victims get some shitty coupons.
I strongly suspect that most class action suits are engineered by the companies themselves. They get free immunity for a relatively small payout to some lawyers
A class action lawsuit is designed to handle the case where individual victims may not be damaged "enough" to justify bringing a lawsuit. But there are lot of victims where it's economically viable to group together everyone as a class to punish the company.
Think of it this way - let's say you sign a contract for new cell phone, $20/month. But then you get your bill and find it's $21. You can call them over and over again and an hour later get your $1 back.Or just forget about it, since in the end it'll be $24 extra. It certainly isn't enough to bring them to court about.
Now, let's say the carrier did this on every customer - if they had a million customers, that's an extra million dollars a month. Enough to make it worthwhile to ALWAYS overcharge people. Individually, no one would be hurt too much - after a few months staying on the phone for an hour to get back $1 is too much work, and they can pocket the extra cash.
At what point is it too much? Perhaps next year they'll overcharge people $2, making a cool 2 million extra dollars every month. It's only $48 people will pay over a 2 year contract, so chance of being sued is low. It's certainly worthwhile to actually do it - free money. Because individually, no one will sue, and you can get away ripping people off.
Hence the class action - companies would get away with this because the damage to individual victims is too low to justify any one of them bringing forward a suit. But collectively, the amount is enough to go after.
As for why the victims get crappy rewards? Well, the whole lawsuit is paid for by the lawyers so all the risk is on them, and the victims themselves are basically getting it for free. Given the victims weren't likely to pursue litigation in the first place, it just means they get reimbursed for free - no risk and it's more than they were getting anyways.
You are free to exclude yourself from any class action you're involved with and bring about your own lawsuit, but chances are you're not going to get much better, especially after time, attorney's fees, etc
TVs and phones have very similar ratios (usually 16:9) so why bother making different versions?
Well, screens are different. Most TV screens are barely sRGB, while most smartphone screens are 100% sRGB, and some are even pushing DCI-P3. But few TV screens are fully Rec.2020 (aka BT.2020, or "HDR" or 4K Wide Color Gamut (WCG)). So color mixing might have to be adjusted. This can be important for HDR movies - if you know your display is WCG, then you can use a full HDR scene. But if it's just SDR (Rec.709/BT.709 for HD) then perhaps brighten the dark areas and dim the bright areas to avoid losing details. Same on mobile screens.
Also, on mobile screens, due to size, if a scene relies on being able to read a headline on a newspaper, or read a piece of paper, then you have to cut it differently - it may be completely illegible on a mobile screen and thus you lose a vital plot point. So for mobile, you might want to zoom into the item and make it fill the screen so it's easier to read. If it's a long block of text, you may have to zoom in and then scroll it. The larger TV screen may just show it in its entirety
This can also apply to small details - you can zoom-cut to them to make it easier to see
At one moment, it feels like such a hip environment, bustling with easy communication and collaboration, innovation and headphones just behind every monitor.
How many employees have ever said this? Open spaces are cheaper per sq ft and allow easier monitoring of personnel, but that doesn't sound good in a pro/con discussion.
No employee never. But it does look impressive for the customers when they see the hustle and bustle that goes on. And if you look at all the TV shows, it looks hip and modern like a startup with people crammed around a long desk.
For a long time you needed 12.04 to build Android, though recent releases allow 14.04 and I think 16.04 without issue But if you have a range of Android versions, 12.04 will build a lot of them.
You cannot determine the price of your products. You cannot impose conditions on goods post-sale. Almost all first-world legal systems prevent such things.
Once the shop has the iPhones in their possession, it's up to THEM what they sell them for, not Apple. Because - for instance - imagine if they DON'T sell. That guy would never be able to recoup even the tiniest part of his money, even at a loss, because "Apple said no".
True. But the manufacturer can get annoyed and you end up screwed.
In the modern world, you can sell your stock on had at whatever price you want, MAP or other agreements be damned. But if you annoy the manufacturer too much doing this, you may find future stock hard to come by.
It's not unusual that this happens. A store decides to put a big discount on a product, against the manufacturer's wishes. They sell through the stock, and order more. But manufacturer simply short ships or delays their delivery - if they order 1000, they may get 100. Or if it's a newly released product, they may get shipment... a week after everyone else.
And no, there is no "retailer non-discrimination act" that would force a manufacturer to be "fair". If a retailer was on particularly good terms, the manufacturer might ship them extra units and early so they are able to sell more.
Why would a web-based frontend to chat use more than 1 percent of CPU time on a desktop or full-size laptop? I could see a problem on a compact laptop with an Atom or ARM CPU, which is designed to sip power rather than run fast.
Good question. It's one of the reasons why I hate slack - the web frontend for it causes Firefox to consume a good 30% CPU! Yes, I've diagnosed it - close the tab, it drops to 0%. Reopen it, back to 30%.
Who knows what crap Slack is running... I gave up and tried their app version, and had to disable every "prettyifying" option to get its usage down. Seems like it displays the text first, then scans it via Javascript seeing if it can search and replace it with some graphics or something. Except, instead of running everytime someone said something, it ran continually.
Uber does have the right to communicate their side of the story to their drivers... somehow this is controversial because... they used their app?
It really depends on the laws. When a unionization drive is taking place, management may be restricted from what they could say and do to employees. In fact, trying to "communicate" about the unionization drive can be considered highly illegal, a form of union busting and land the employer in a LOT of hot water. (E.g., if the drive does not succeed, but a sizable group still wants it, the courts could still decide to certify the union anyways, assuming the communications forced people to not join. And it doesn't matter if in a free vote the union wouldn't have the majority - i.e., had the employer not interfered, the union vote would've failed).
You might think employers have a right to communicate, but depending on the labor laws, this is not necessarily true.
Harldy anyone disputes the fact there is global warming. The dispute is over how much of it we're causing and whether or not its actually abnormal given that in the history of the planet it has been far warmer many many times over the millennia. Then there's what we should do about it and given how almost every other month something new is being found out about our climate and what affects it I hardly think we're in a position to be deliberately messing about with it. Sure reduce/eliminate what we put in the air etc but when you start doing things like schemes to reflect the sun, artificially forcing rain etc then we may find we're doing more harm than good.
If the chart is accurate, "far warmer many many times" is inaccurate - we're at the peak already and even the most harsh scenarios for reversing it will have the climate get warmer still.
A bit of wood glue and carbon paper and you can take a snapshot of a fingerprint smudge on a screen, and turn it into an authenticatable fingerprint in about five minutes.
All fingerprint readers suffer the same problem, to differing degrees, but a fingerprint is bog-useless for "securing" your phone. It's literally in the "prank on your friends" territory to unlock it.
There's a reason that my Samsung shows several different lock screen methods (swipe, PIN, passcode, etc.), each with a security (High Security, Medium Security, Low Security, etc.) underneath and the fingerprint one? It says NOTHING underneath. Just a blank space where they should be saying "Waste of time"
The point of the fingerprint reader is not for security, but for convenience.
Apple found a LOT of people did not put even a 4-digit PIN on their phones. Why? Because the users found it too inconvenient. And the average use case bears this out - a phone is interacted with hundreds to thousands of times a day, and each interaction lasts only a few seconds - either to glance at a message, check out information, etc. For these uses, entering a PIN takes a few MORE seconds, easily doubling the interaction time.
Instead of grouping interactions together so one unlock you do many things, Apple discovered users were simply disabling the locks so they didn't have to bother with the PIN codes that delayed the interactions. Thus, it ended up with something like 75% of all phones, despite having the capability for locking access down, were left in the open state.
Hence the fingerprint reader - it allowed the user to put on a lock on their phone, but also allow a quick unlock for interactions.
A fingerprint is not secure - even Apple treats it as such, which is why the fingerprint is disabled after several invalid tries (use other authentication method, like PIN), after a reboot, or after 48 hours. It's there to provide the user with a convenient way to unlock their phone, as well as having it locked down so it's not so inconvenient.
I am quite understanding of console makers' desire to protect their consoles from running pirated games. I am less understanding when their anti-piracy measures go as far as to block backups of saved games, which means if you have to send your console in for repair all your saved games may very well get wiped. There are already horror stories about the Switch in this regard. I fully support homebrew on the Switch if only to fix this intentional flaw. If it enables piracy in the process, too bad for Nintendo. They should have learned their lessons like Valve did when they created Steam and totally owned the PC gaming market.
Well, the flash memory of the Switch is actually on a separate removable board. You almost never do this unless you intend for the memory to be moved between units - especially in a console where cost is king. The fact that the eMMC is deliberately on a separate board (with separate costs in production, connectors, reduced reliability, etc) instead of soldered to the main board like every other eMMC chip out there implies that it was designed to be moved.
And a lot of hacks have come by way of save games - so much so that Microsoft started signing xbox360 saves so they couldn't be edited (this too after people started moving saves around to get achievements).
I believe that this is the more likely scenario: They are interviewing for a specific job. They tell him the job involves doing work that can't be done at home. They tell him the job will involve working after hours from time to time on things that cannot be done at home. He accepts the job offer and then on the first day of employment says he cannot do the job for which he was hired, rather he would like to do the job for which he would have liked to have been hired. The company says no, he cries to the media.
Even so, it was only a highly temporary arrangement. His wife had a few weeks to live (the article notes she passed a couple of months after the incident). Once she passed, he would be free to go to the office and live there if need be. Just in the meantime, a little consideration would be nice.
And no, stuff like this doesn't need to be mentioned during the job interview. (A company wouldn't want to know it, anyways, because it increases the risk of a discrimination lawsuit.)
Life happens. Timing can suck at times - think companies don't have to deal with new hires that suddenly need to go on maternity leave? (Some companies take a few months to hire - what would've been the employee working a few months while pregnant turns into the employee needing to take leave within a few weeks of being hired).
The situation was at most temporary. It may be an issue if it was dragging on for a year, but the doctors gave only weeks (2 weeks to 2 months).
And chances are, at his position, even though he's probably have to be in the office, he'd very likely not have to work overtime (government contractor and all).
So it's not only a temporary situation, but one that's very unlikely to happen over the two months.
And the supervisor was probably correct - it didn't matter to him and being human was the best thing possible. I've had to tell coworkers to simply go home or to not worry about things when they needed to take care of someone. Granted, I don't have the authority to do so, but I will defend my decision as a decent human being trying to be compassionate. There is no work so important that it cannot wait until the next day that cannot be temporarily handled by someone else that would justify lack of compassion.
Is it more reasonable to assume that the markets have legitimately drained the supply, or that the whole industry is keeping a lid on it? SSDs seem to have become nigh ubiquitous on the convertible laptop/tablets, and an extremely common upgrade for even low-end laptops... Also, older news on this (i see things dating from Q4'16) offered the suggestion that relief might be coming by now. https://www.theregister.co.uk/...
At any rate, let's just hope that as many manufacturers as possible survive as long as possible to avoid establishing one of them as the WD of NAND. Hopefully things will stay competitive for a while longer.
It's a careful balance. In fact, Apple may be a huge cause for the shortage as they use enough of it to actually be able to influence prices - Apple buys so much, and everyone else gets the leftovers. If Apple needs more of them, then Apple pays a price, and the leftovers get less. Could they make more? Perhaps, but it's a balance - manufacturers don't want to make too much otherwise prices will drop substantially.
In fact, it's why Kingston is around - they serve as a general buffer for production - if too much was produced, they use Kingston to soak up the excess (it's why Kingston devices almost always have varying quality - they really build depending on what they can get).
If Apple is anticipating a high demand for iPhone 8 phones, then they could be buying up flash chips well in advance to ensure they have a supply. (Manufacturers could make more, but then if Apple doesn't order as much next year all of a sudden you have to idle production lines and that's a bad thing).
There are only a few manufacturers of NAND flash - Toshiba (now Western Digital), Samsung, Intel and a couple of others.
Slashdot does have a naÃfve implementation of text. While there is a whole smÃfrgÃfÂ¥sbord of options UTF-8 is a pretty well established standard. It's embarrassing for a site whose raison d'Ãftre is technology. Maybe a bounty of say ã100 would encourage someone to fix it.
Seriously though, what does prevent Slashdot from handling it properly? Surely the text gets entered and stored in the DB as UTF-8. A fix can't be too difficult to implement.
Slashdot is fully unicode compatible. (It was the work of slashdot.jp a long, long, long time ago that did it).
I can't tell you if they use UTF-8 internally or what, but it doesn't matter.
The reason it appears to not work is because of unicode abuse by commenters. And if you go into many forums that naively implement Unicode support, you will see trolls that create posts that are miles long by simply abusing Unicode adornments. Or ones that reverse the text layout (RTL/LTR override), which was very popular on Slashdot in the early days.
So what happened? They implemented both an input and output filter - every character is scanned against an input white list, and when displaying, every character is scanned against an output whitelist (those LTR/RTL overrides are still in the comments in the database, so they now get stripped before display).
Google "site:slashdot.org erocS" if you want to see some examples of Unicode abuse. The strange word is "Score", if you didn't figure it out, and putting "Score:5" with RTL override was a popular way of "upvoting" your posts.
Unicode is complex, and you cannot blindly support it without restricting usage, especially in today's day and age.
Correct me if I'm wrong, but wouldn't an ammeter need to be put directly in series in the wiring? I seem to remember that voltage and resistence can be measured in parallel, but not current.....
"Clamp meters".
Most common are AC ones - you clamp them around an AC line and a current is induced in the clamp meter's clamp. The strength of the magnetic field around the AC line is proportional to current and thus the induced current in the clamp meter is proportional to current, where it's measured, calculated and displayed.
They also make DC clamp meters that don't rely on inducing a current in a coil - but instead use hall effect sensors to measure the strength of the magnetic field induced.
Gnome3 and its ilk, are the result of developers (and especially designers) not listening to their userbase.
"But the menu based metaphor systems are so... OLD!" is not a justifiable excuse for not respecting user feedback about your choices as the dev team/designer.
The same same is true for things like Pottering's systemd. "Script based inits, like found in sysv init, are just so OLD!" is not a justifiable excuse for its removal.
If you are a developer/designer, and you disagree with my attestation that just because something is old does not mean you should remove it (or replace it with something else), take this to heart:
Or the userbase has shifted.
Once upon a time, it was acceptable that devices could monopolize the audio device. No longer. Once upon a time, you could count on audio devices being static. No longer. Once upon a time, you could count on users dynamically adding and removing audio devices and expecting those devices to be usable without the underlying program opening them explicitly. No longer.
It's things that Windows and macOS do just fine. You connect your Bluetooth headset (or USB headset) and automagically, your communications apps switch over to using them without you closing them, or without them explicitly opening them - they opened the audio device and didn't care which it was. The user may use the built in microphone and speakers, then wanting a bit more privacy, plug in a headset (USB, Bluetooth, it doesn't matter), and then continue their conversation in private without doing anything else. The communications app didn't close and was reopened by the user - the user simply continued their existing conversation just fine, using a new audio device that wasn't there when the app started. And without special coding on the app's part to scan for new audio devices and ask the user if they wanted to switch over to using it.
Once upon a time, network configurations never changed. No longer. Once upon a time, when you connected to a network, it was the same network. No longer. Once upon a time, when the network connected, you could use it immediately. No longer.
Users connect to wifi promiscuously. One moment, they may be at work and on the corporate LAN over WiFI. The next moment they may be at Starbucks - and seeing that the connection is open, the OS should offer to launch a VPN client (no OS does this, yet, though Nexus/Pixel Androids do ask sometimes) to connect back to the office, or offer to secure the WiFi connection. And of course, the firewall should be enabled at its strictest setting.for out-of-LAN networks.
Likewise, script-based inits make no sense - why do you emulate what init can already do - maintain daemons? If a daemon crashes or exits, init (sysvinit) can already relaunch it. And if it dies too fast, init can pause launching it for a few minutes so you can have a system youc an debug with. Plus, it keeps track of the runlevels too, so you don't have to make sure your S/K scripts balance. (And switching is so inefficient when you have to K the service, then switch over and then relaunch it afterwards if both runlevels have the same service).
Of course, every other major Unix-based OS has their own system, which should say something. (Android as well).
Just because you liked how simple things in the past were, doesn't mean today they're still relevant. Sure it's nice, but the demands of a modern OS have gotten much more complex.
What killed netbooks was the pricing. $300 for a laptop? Consumers were happy, but manufacturers were basically shaving costs everywhere to meet the price point. It was almost a money-losing machine - margins were very thin.
And those machines were cut to the very bare bones.
Then they started machine machines with bigger screens, bigger keyboards, more memory, etc. And manufacturers were happy - they could upgrade the screen from a 800x480 screen to a 1024x768 (from 7" to 8 or 9") and charge another $100 for it - so the price of netbooks kept creeping up. Until a nice netbook started costing from $500 and more - I think a fully equipped one started costing up to $750. At which point you pause - because that's laptop range in pricing. With people wanting the stuff in more expensive netbooks, the cheap ones died off as the more expensive ones had higher margins.
Then tablets came out. What the iPad did was basically what everyone wanted in a netbook - a way to consume content. They liked the smaller form factor of a netbook because it was easier to read books in bed with a smaller, lighter machine. It was great for people to watch their Netflix on. But then tablets came out and could do that easier and better, and had even higher margins to boot, dropping the netbook.
The most spartan designs might not need a 'codec' at all(you can get MEMs mics that speak I2S directly, with the analog support circutry integrated into the package; and you can also get audio amps/speaker/headphone drivers that speak I2S directly and have a DAC onboard, rather than accepting a low voltage analog audio input); but if you've got a mic array, a speaker, headphone/mic jack, line out, etc. a codec can bundle up all the support for the various analog interfaces and allow you to attach them all to the SoC/chipset with a single digital bus.
In this case, the fact that it's a codec soldering issue is presumably why all three mics die at once. That would be seriously unlikely if the mics themselves failed; but the codec handles all the mics, so a failure there knocks out the mics in roughly the same way that just yanking out a soundcard would.
Actually, for microphones, you don't usually use analog ones hooked to a codec providing the data via I2S in modern phones.
You use "digital microphones" that output PDM coded audio directly (PDM = pulse density modulation - the higher the signal value, the closer the pulses are together). PDM has a trade name of DSD (Direct Stream Digital) as it's the format used by Soper Audio CD and "1-bit DACs". (They only output 1s and 0s, the density of 1s describes the signal level).
This lets you connect up an array of microphones (usually at least 3 on modern phones) using minimal pins and support electronics - a PDM microphone takes just 2 wires - clock (in) and data (out), and if you have an array, they can share a clock line so your 3 microphones use just 4 lines.
A crack on the clock line would easily disable all the microphones.
Because it's testable? The vulnerabilities are known now. You can easily take an iOS device, update it and test to see how many vulnerabilities are fixed and how many are still open.
And Apple opensources the core - the kernel and low level code is open source. Not that it means it's bug free (Heartbleed anyone? Shellshock?) since many can exist for years before discovery and exploit.
Hyperloop is cool, especially if you're a fan of William F. Nolan and George Clayton Johnson's science fiction works, but it has all of the downsides of maglev combined with all of the downsides of building subways, so the ridership would have to be massive to make it cost effective.
But there already are routes where this is the case - high volume routes with lots of people heading one way or another. LA to San Francisco is one, but there are many more where there are many flights per day between two destinations.
Hell, Japan would be a good spot to test it. Boeing has to write a special manual for their 747's because a LOT of them are used simply for short haul flights. Just a lot of people.
A hyperloop wouldn't be for your milk run commuters - they'd be for the longer hauls.
Intel is not worried. How is ARM any more of a threat today than AMD was?
Intel started building lower powered chips a long time ago to compete with ARM and have, in a number of areas, surpassed them. Time and again, Intel has been able to ramp up their R&D to stave off serious competition. I don't see ARM being any different.
Exactly.
ARM will not replace Intel in the high-power CPU market. The one that's Intel's bread and butter with Xeons that cost $10,000+.
ARM will however replace the lower power CPU market - the ones where servers are either virtualized, or their tasks are light enough that CPU was never a problem. Think of things like web servers and other internet servers - the task is light duty and can be fulfilled by very low end machines. ARMs will excel here, and in many cases, you can fit easily 32+ ARM servers in a 1U form factor.
Maybe the biggest people who should worry are VM developers - if you have lightweight tasks that you could put into VMs, but now you can run them on a physical machine that takes little space, it becomes an option. Fitting 32 VMs on a 1U server is difficult, for example.
That's not to say there isn't an advantage to VMs, so they'll still be around (we won't have a mass "physicalization" of people moving VMs to physical machines again)
So, Just like Snowden, let's ignore the purportedly criminal and corrupt activity of the US Government and it's elected thugs - and just kill the messenger. Sweep the body under the run and strong arm anyone with evidence to go away. Case Closed, mission accomplished, normality achieved.
Note your president. Who during the campaign relished the fact Wikileaks was helping him.
Now that his presidency is being challenged by leaks, he's cracking down on whistleblowers, examining white house staff's phones (especially looking for apps like Signal), etc.
Leaks that make him look good, he likes. Leaks that make him look bad, send in the marines.
One example is playing silent audio while streaming via DLNA from the iOS device to prevent the OS from putting the app to sleep after 10 minutes or so. A big company just does it and has done it for years without consequence. Another small developer in my niche needed to do this as well, but was forced by Apple to remove it unless there was a specific function for it. So the developer instead added a useless "visualizer" that made graphic effects to music picked up by the microphone which is then put in the background and hidden - just to get around the rules. I have not added DLNA streaming yet because of these headaches.
Actually, Facebook (who did this for a few years) stopped because doing so drains the battery really quickly. A few developers were curious why they were getting really short battery life and discovered the Facebook app was running a lot because of this, and Apple had them stop.
If you do use this trick, people do know since it has a marked difference in battery life.
Well, if they properly set up the network, it's likely the payment network is secure and isolated from the corporate network. The corporate network is a bit more "open" to allow employees to do their jobs and engineering and all that, and it's likely that makes it a good target for breaches - because if there's any information on vulnerabilities on the payment network, or their payment devices, it would be on the corporate network.
So if they do this right, no customer data was breached (other than perhaps their customers information), but they should automatically change all the passwords on their payment network side as a security precaution in case it was available on the corporate network side.
Slashdot Mirror
You can send it as binary - use HTTP compression. I believe most webservers support it as do webbrowsers, so the javascript file is compressed and the compressed binary is sent over the wires, and the web browser will decompress the blob back to the original javascript.
The problem is needing to drive in the first place.
In places with good public transportation (e.g., Europe), you don't need to drive - you can get around pretty damn effectively with just public transportation. Hell, you can even get between cities taking the trains and planes and never needing to step in a car.
Problem is, then you go to places like North America, where the vast majority of cities are car-only. Walking only gets you from one big box store to another (assuming you can cross that 10 lane highway in-between them), and public transit is non-existent. There you less WANT to drive but instead NEED to drive.
Driving's a chore. It's something most drivers in North America don't want to do (as evidenced by their attention being held elsewhere, typically on small handheld devices). What needs to be done is eliminating the need to drive, so those who drive are those that want to.
A class action lawsuit is designed to handle the case where individual victims may not be damaged "enough" to justify bringing a lawsuit. But there are lot of victims where it's economically viable to group together everyone as a class to punish the company.
Think of it this way - let's say you sign a contract for new cell phone, $20/month. But then you get your bill and find it's $21. You can call them over and over again and an hour later get your $1 back.Or just forget about it, since in the end it'll be $24 extra. It certainly isn't enough to bring them to court about.
Now, let's say the carrier did this on every customer - if they had a million customers, that's an extra million dollars a month. Enough to make it worthwhile to ALWAYS overcharge people. Individually, no one would be hurt too much - after a few months staying on the phone for an hour to get back $1 is too much work, and they can pocket the extra cash.
At what point is it too much? Perhaps next year they'll overcharge people $2, making a cool 2 million extra dollars every month. It's only $48 people will pay over a 2 year contract, so chance of being sued is low. It's certainly worthwhile to actually do it - free money. Because individually, no one will sue, and you can get away ripping people off.
Hence the class action - companies would get away with this because the damage to individual victims is too low to justify any one of them bringing forward a suit. But collectively, the amount is enough to go after.
As for why the victims get crappy rewards? Well, the whole lawsuit is paid for by the lawyers so all the risk is on them, and the victims themselves are basically getting it for free. Given the victims weren't likely to pursue litigation in the first place, it just means they get reimbursed for free - no risk and it's more than they were getting anyways.
You are free to exclude yourself from any class action you're involved with and bring about your own lawsuit, but chances are you're not going to get much better, especially after time, attorney's fees, etc
Well, screens are different. Most TV screens are barely sRGB, while most smartphone screens are 100% sRGB, and some are even pushing DCI-P3. But few TV screens are fully Rec.2020 (aka BT.2020, or "HDR" or 4K Wide Color Gamut (WCG)). So color mixing might have to be adjusted. This can be important for HDR movies - if you know your display is WCG, then you can use a full HDR scene. But if it's just SDR (Rec.709/BT.709 for HD) then perhaps brighten the dark areas and dim the bright areas to avoid losing details. Same on mobile screens.
Also, on mobile screens, due to size, if a scene relies on being able to read a headline on a newspaper, or read a piece of paper, then you have to cut it differently - it may be completely illegible on a mobile screen and thus you lose a vital plot point. So for mobile, you might want to zoom into the item and make it fill the screen so it's easier to read. If it's a long block of text, you may have to zoom in and then scroll it. The larger TV screen may just show it in its entirety
This can also apply to small details - you can zoom-cut to them to make it easier to see
No employee never. But it does look impressive for the customers when they see the hustle and bustle that goes on. And if you look at all the TV shows, it looks hip and modern like a startup with people crammed around a long desk.
Of course, looks can be deceiving.
For a long time you needed 12.04 to build Android, though recent releases allow 14.04 and I think 16.04 without issue But if you have a range of Android versions, 12.04 will build a lot of them.
True. But the manufacturer can get annoyed and you end up screwed.
In the modern world, you can sell your stock on had at whatever price you want, MAP or other agreements be damned. But if you annoy the manufacturer too much doing this, you may find future stock hard to come by.
It's not unusual that this happens. A store decides to put a big discount on a product, against the manufacturer's wishes. They sell through the stock, and order more. But manufacturer simply short ships or delays their delivery - if they order 1000, they may get 100. Or if it's a newly released product, they may get shipment... a week after everyone else.
And no, there is no "retailer non-discrimination act" that would force a manufacturer to be "fair". If a retailer was on particularly good terms, the manufacturer might ship them extra units and early so they are able to sell more.
Good question. It's one of the reasons why I hate slack - the web frontend for it causes Firefox to consume a good 30% CPU! Yes, I've diagnosed it - close the tab, it drops to 0%. Reopen it, back to 30%.
Who knows what crap Slack is running... I gave up and tried their app version, and had to disable every "prettyifying" option to get its usage down. Seems like it displays the text first, then scans it via Javascript seeing if it can search and replace it with some graphics or something. Except, instead of running everytime someone said something, it ran continually.
It really depends on the laws. When a unionization drive is taking place, management may be restricted from what they could say and do to employees. In fact, trying to "communicate" about the unionization drive can be considered highly illegal, a form of union busting and land the employer in a LOT of hot water. (E.g., if the drive does not succeed, but a sizable group still wants it, the courts could still decide to certify the union anyways, assuming the communications forced people to not join. And it doesn't matter if in a free vote the union wouldn't have the majority - i.e., had the employer not interfered, the union vote would've failed).
You might think employers have a right to communicate, but depending on the labor laws, this is not necessarily true.
ObXKCD: https://xkcd.com/1732/
If the chart is accurate, "far warmer many many times" is inaccurate - we're at the peak already and even the most harsh scenarios for reversing it will have the climate get warmer still.
The point of the fingerprint reader is not for security, but for convenience.
Apple found a LOT of people did not put even a 4-digit PIN on their phones. Why? Because the users found it too inconvenient. And the average use case bears this out - a phone is interacted with hundreds to thousands of times a day, and each interaction lasts only a few seconds - either to glance at a message, check out information, etc. For these uses, entering a PIN takes a few MORE seconds, easily doubling the interaction time.
Instead of grouping interactions together so one unlock you do many things, Apple discovered users were simply disabling the locks so they didn't have to bother with the PIN codes that delayed the interactions. Thus, it ended up with something like 75% of all phones, despite having the capability for locking access down, were left in the open state.
Hence the fingerprint reader - it allowed the user to put on a lock on their phone, but also allow a quick unlock for interactions.
A fingerprint is not secure - even Apple treats it as such, which is why the fingerprint is disabled after several invalid tries (use other authentication method, like PIN), after a reboot, or after 48 hours. It's there to provide the user with a convenient way to unlock their phone, as well as having it locked down so it's not so inconvenient.
Well, the flash memory of the Switch is actually on a separate removable board. You almost never do this unless you intend for the memory to be moved between units - especially in a console where cost is king. The fact that the eMMC is deliberately on a separate board (with separate costs in production, connectors, reduced reliability, etc) instead of soldered to the main board like every other eMMC chip out there implies that it was designed to be moved.
And a lot of hacks have come by way of save games - so much so that Microsoft started signing xbox360 saves so they couldn't be edited (this too after people started moving saves around to get achievements).
Even so, it was only a highly temporary arrangement. His wife had a few weeks to live (the article notes she passed a couple of months after the incident). Once she passed, he would be free to go to the office and live there if need be. Just in the meantime, a little consideration would be nice.
And no, stuff like this doesn't need to be mentioned during the job interview. (A company wouldn't want to know it, anyways, because it increases the risk of a discrimination lawsuit.)
Life happens. Timing can suck at times - think companies don't have to deal with new hires that suddenly need to go on maternity leave? (Some companies take a few months to hire - what would've been the employee working a few months while pregnant turns into the employee needing to take leave within a few weeks of being hired).
The situation was at most temporary. It may be an issue if it was dragging on for a year, but the doctors gave only weeks (2 weeks to 2 months).
And chances are, at his position, even though he's probably have to be in the office, he'd very likely not have to work overtime (government contractor and all).
So it's not only a temporary situation, but one that's very unlikely to happen over the two months.
And the supervisor was probably correct - it didn't matter to him and being human was the best thing possible. I've had to tell coworkers to simply go home or to not worry about things when they needed to take care of someone. Granted, I don't have the authority to do so, but I will defend my decision as a decent human being trying to be compassionate. There is no work so important that it cannot wait until the next day that cannot be temporarily handled by someone else that would justify lack of compassion.
Slashdot is fully unicode compatible. (It was the work of slashdot.jp a long, long, long time ago that did it).
I can't tell you if they use UTF-8 internally or what, but it doesn't matter.
The reason it appears to not work is because of unicode abuse by commenters. And if you go into many forums that naively implement Unicode support, you will see trolls that create posts that are miles long by simply abusing Unicode adornments. Or ones that reverse the text layout (RTL/LTR override), which was very popular on Slashdot in the early days.
So what happened? They implemented both an input and output filter - every character is scanned against an input white list, and when displaying, every character is scanned against an output whitelist (those LTR/RTL overrides are still in the comments in the database, so they now get stripped before display).
Google "site:slashdot.org erocS" if you want to see some examples of Unicode abuse. The strange word is "Score", if you didn't figure it out, and putting "Score:5" with RTL override was a popular way of "upvoting" your posts.
Unicode is complex, and you cannot blindly support it without restricting usage, especially in today's day and age.
"Clamp meters".
Most common are AC ones - you clamp them around an AC line and a current is induced in the clamp meter's clamp. The strength of the magnetic field around the AC line is proportional to current and thus the induced current in the clamp meter is proportional to current, where it's measured, calculated and displayed.
They also make DC clamp meters that don't rely on inducing a current in a coil - but instead use hall effect sensors to measure the strength of the magnetic field induced.
Or the userbase has shifted.
Once upon a time, it was acceptable that devices could monopolize the audio device. No longer. Once upon a time, you could count on audio devices being static. No longer. Once upon a time, you could count on users dynamically adding and removing audio devices and expecting those devices to be usable without the underlying program opening them explicitly. No longer.
It's things that Windows and macOS do just fine. You connect your Bluetooth headset (or USB headset) and automagically, your communications apps switch over to using them without you closing them, or without them explicitly opening them - they opened the audio device and didn't care which it was. The user may use the built in microphone and speakers, then wanting a bit more privacy, plug in a headset (USB, Bluetooth, it doesn't matter), and then continue their conversation in private without doing anything else. The communications app didn't close and was reopened by the user - the user simply continued their existing conversation just fine, using a new audio device that wasn't there when the app started. And without special coding on the app's part to scan for new audio devices and ask the user if they wanted to switch over to using it.
Once upon a time, network configurations never changed. No longer. Once upon a time, when you connected to a network, it was the same network. No longer. Once upon a time, when the network connected, you could use it immediately. No longer.
Users connect to wifi promiscuously. One moment, they may be at work and on the corporate LAN over WiFI. The next moment they may be at Starbucks - and seeing that the connection is open, the OS should offer to launch a VPN client (no OS does this, yet, though Nexus/Pixel Androids do ask sometimes) to connect back to the office, or offer to secure the WiFi connection. And of course, the firewall should be enabled at its strictest setting.for out-of-LAN networks.
Likewise, script-based inits make no sense - why do you emulate what init can already do - maintain daemons? If a daemon crashes or exits, init (sysvinit) can already relaunch it. And if it dies too fast, init can pause launching it for a few minutes so you can have a system youc an debug with. Plus, it keeps track of the runlevels too, so you don't have to make sure your S/K scripts balance. (And switching is so inefficient when you have to K the service, then switch over and then relaunch it afterwards if both runlevels have the same service).
Of course, every other major Unix-based OS has their own system, which should say something. (Android as well).
Just because you liked how simple things in the past were, doesn't mean today they're still relevant. Sure it's nice, but the demands of a modern OS have gotten much more complex.
Kinda, sorta.
What killed netbooks was the pricing. $300 for a laptop? Consumers were happy, but manufacturers were basically shaving costs everywhere to meet the price point. It was almost a money-losing machine - margins were very thin.
And those machines were cut to the very bare bones.
Then they started machine machines with bigger screens, bigger keyboards, more memory, etc. And manufacturers were happy - they could upgrade the screen from a 800x480 screen to a 1024x768 (from 7" to 8 or 9") and charge another $100 for it - so the price of netbooks kept creeping up. Until a nice netbook started costing from $500 and more - I think a fully equipped one started costing up to $750. At which point you pause - because that's laptop range in pricing. With people wanting the stuff in more expensive netbooks, the cheap ones died off as the more expensive ones had higher margins.
Then tablets came out. What the iPad did was basically what everyone wanted in a netbook - a way to consume content. They liked the smaller form factor of a netbook because it was easier to read books in bed with a smaller, lighter machine. It was great for people to watch their Netflix on. But then tablets came out and could do that easier and better, and had even higher margins to boot, dropping the netbook.
Actually, for microphones, you don't usually use analog ones hooked to a codec providing the data via I2S in modern phones.
You use "digital microphones" that output PDM coded audio directly (PDM = pulse density modulation - the higher the signal value, the closer the pulses are together). PDM has a trade name of DSD (Direct Stream Digital) as it's the format used by Soper Audio CD and "1-bit DACs". (They only output 1s and 0s, the density of 1s describes the signal level).
This lets you connect up an array of microphones (usually at least 3 on modern phones) using minimal pins and support electronics - a PDM microphone takes just 2 wires - clock (in) and data (out), and if you have an array, they can share a clock line so your 3 microphones use just 4 lines.
A crack on the clock line would easily disable all the microphones.
Because it's testable? The vulnerabilities are known now. You can easily take an iOS device, update it and test to see how many vulnerabilities are fixed and how many are still open.
And Apple opensources the core - the kernel and low level code is open source. Not that it means it's bug free (Heartbleed anyone? Shellshock?) since many can exist for years before discovery and exploit.
See the open source stuff for Apple here: https://opensource.apple.com/
But there already are routes where this is the case - high volume routes with lots of people heading one way or another. LA to San Francisco is one, but there are many more where there are many flights per day between two destinations.
Hell, Japan would be a good spot to test it. Boeing has to write a special manual for their 747's because a LOT of them are used simply for short haul flights. Just a lot of people.
A hyperloop wouldn't be for your milk run commuters - they'd be for the longer hauls.
Exactly.
ARM will not replace Intel in the high-power CPU market. The one that's Intel's bread and butter with Xeons that cost $10,000+.
ARM will however replace the lower power CPU market - the ones where servers are either virtualized, or their tasks are light enough that CPU was never a problem. Think of things like web servers and other internet servers - the task is light duty and can be fulfilled by very low end machines. ARMs will excel here, and in many cases, you can fit easily 32+ ARM servers in a 1U form factor.
Maybe the biggest people who should worry are VM developers - if you have lightweight tasks that you could put into VMs, but now you can run them on a physical machine that takes little space, it becomes an option. Fitting 32 VMs on a 1U server is difficult, for example.
That's not to say there isn't an advantage to VMs, so they'll still be around (we won't have a mass "physicalization" of people moving VMs to physical machines again)
Note your president. Who during the campaign relished the fact Wikileaks was helping him.
Now that his presidency is being challenged by leaks, he's cracking down on whistleblowers, examining white house staff's phones (especially looking for apps like Signal), etc.
Leaks that make him look good, he likes. Leaks that make him look bad, send in the marines.
Actually, Facebook (who did this for a few years) stopped because doing so drains the battery really quickly. A few developers were curious why they were getting really short battery life and discovered the Facebook app was running a lot because of this, and Apple had them stop.
If you do use this trick, people do know since it has a marked difference in battery life.
Well, if they properly set up the network, it's likely the payment network is secure and isolated from the corporate network. The corporate network is a bit more "open" to allow employees to do their jobs and engineering and all that, and it's likely that makes it a good target for breaches - because if there's any information on vulnerabilities on the payment network, or their payment devices, it would be on the corporate network.
So if they do this right, no customer data was breached (other than perhaps their customers information), but they should automatically change all the passwords on their payment network side as a security precaution in case it was available on the corporate network side.