Posts by doublelayer 9408 publicly visible posts • joined 22 Feb 2018
While I'm not aware of Joseph Simons having done anything to bring on ire, it's possible that the original poster was instead referring to the person who currently has the power to remove and replace commissioners should they wish to mess with something. Maybe the post was intending to call for increased oversight of a bureaucratic entity should its powers be increased. Or maybe it was just an acronym confusion. I'm not sure.
"Have we really become such an emotionally weak society that out up-line managers must spend time worrying about out "mental well being" that worrying about getting the job done and making the company more profitable?"
Not quite. It's always been the job of a manager to worry about such things because the workers' mental wellbeing directly affects their productivity. If workers hate you, they'll try to leave and you'll have to hire new ones. Reduced profit. If workers are constantly distracted by a poor working environment, they'll get less done. Reduced profit. If workers are in a combative environment where they have to essentially fight against one another, then they'll spend time defending themselves or planning their own attacks instead of getting stuff done. Reduced profit. If workers are subject to too much work and burn out, expect them to have other health problems, therefore taking more time off and reducing productivity. Reduced profit. It's been known for as long as there have been workers who had a choice about whether to stay working for the company; it is the managers' responsibility to ensure that workers are in a good enough condition to continue doing work, and those who fail to do it usually see productivity slump.
Depends on the state of the office. Put me in an open plan office without restrictions about noise levels, even requiring me to stay there and looking at least a bit productive for all my allotted hours, and I assure you I'll be less productive than at home, where things are quiet, even if I take breaks more than they'd like. The same can be true for lots of environmental differences, from noise to equipment to socialization.
As it happens, your comment is correct for my current home and office setup, because my office had full walls and also gave me an easier way to quickly check things with others. When my team members all return to the office, I'll be there too and I'll be cheerful about it. It could definitely go the other way for lots of people.
Again, it doesn't help against anyone else. If he could do it, anyone else could do it. If he was going to do anything dangerous, he'd have done it before, or instead of, telling someone about the problem. It's missing the point and badly to think about sacking him; either you don't care enough about the stuff in the safes to go to the expense of updating the locks in which case you can ignore the problem, or you do in which case your attack landscape is anyone and everyone who could conceivably get to the safes. It sounds like they completely ignored this, and given that their project was being spied on by Soviet agents which they'd rather not have know the information, they probably should have put some thought into it.
I don't think that's the correct response. I have not read his account, although I've just put it on my reading list which is a LIFO stack so I will have soon, so I'm going with the summary outlined above, but in that case, it was a terrible response. If the comment I'm referring to is correct, the reason he could break in was that people were using a small set of combinations and the locks were shoddy enough to take several possibilities. The second problem is expensive to fix, but the first is not. Ban the default combination and require people to change it, with an explanation of how to do so randomly. That should dramatically worsen the chances of having a code which unlocks all the safes or brute forcing a small number of possibilities while distracting the safe's owner.
In addition, this was a government project with a massive budget holding state secrets; if security isn't relevant there, what is the point? Blocking one person from accessing safes protects you against that person, who already proved he was on your side by reporting this instead of stealing the information and choosing his next nation of residence. It does not protect you from anyone who read his report, heard it from him, or figured out the same thing. If they're not on your side, you won't find out until after they've exploited the problem. This is what happens to the least sympathetic of data breech victims; they know there is a problem, know why there is a problem, know how to fix the problem, don't fix the problem, and people suffer as a result. Don't do it.
Welcome to the world of used devices. When you go online and buy a used device, it's usually not from the manufacturer. It's from some user who may or may not have damaged the device, meaning you know you're entering the realm of possibly extensive damage. The same is true if you buy from these recyclers or if you buy from someone random who lives near you; there's always the chance that what they call "lightly used" means "only dropped on concrete three or four times". For this reason, I rarely if ever buy used devices that I think are likely to have become damaged, phones among them. When buying other used devices, I require that I get to test things before payment. Those who choose to enter this market know what they're getting into. I have no reason to believe that the phones sold this time were any worse than the average user-sold used device.
That said, it is still a breech of Apple's contract, which is a legal contract. I would prefer that the contract didn't get made, but it was. I'm not saying here that what the recycler's employees did was right or that they should get away with it without consequence.
The article states that the company concerned also operated in the United States at the time, to say nothing of the possibility that phones were shipped to the Canadian recycling facility to take advantage of a good recycling rate or cheap electrical power. We really don't know how many devices were recycled by Apple at all, given that we don't know how many companies they use to recycle for them.
You are trying to prove that Apple's devices are unusually bad, which is going to require extra levels of proof. Their repairability scores aren't great, but their competitors' aren't either. If you want to ban Apple devices for sustainability problems, which they have, you should also prepare for most competitors to be banned as well. Only a few phones I know of are easy to repair, including the Fairphone, PinePhone, etc. so you might be left with only those.
"not sure: if Apple handed them to the recycling firm, then the recycling firm owned them."
Almost certainly not. Apple could have done it two ways:
1. "Here are some phones we don't want. You can buy them and obtain value from them. You have to be environmentally-focused if you get rid of parts." Results in the recycling firm owning the devices.
2. "Here are some phones we don't want. We want them recycled, you recycle, so we'll pay you to recycle them." Apple still own the devices.
I think Apple chose option 2, in which case they are paying the company to do something with the things Apple owns. Since the recycling company didn't own them, they can't cancel the contract on right-to-repair because the devices are not theirs to repair.
I would prefer that the devices get reused when possible, but it's helpful to recognize what legal rights Apple has in this situation if only to suggest ways to make it less likely to happen next time.
Depending on the history of those drives, the total destruction contract might have been more relevant. If they previously held sensitive information, the destruction could have been to eliminate that rather than to push demand for newer disks. I would be very angry if I gave disks to someone for destruction but they didn't do it. Then again, such concerns shouldn't apply to Apple devices since the internal storage is flash and encrypted with a separate location for key storage, so an erase should be nearly impossible to recover from.
This assumes that ARM is going to be critical to all OSes in the future. Given that the public doesn't know what ARM is, that's a hard point to prove. Intel's problems in speeding up their chips are well-known, but AMD has succeeded in producing X64 chips with a smaller lithography and they're starting to get into the low-power space. Meanwhile, Intel still has a bunch of cash to throw at their problems.
ARM has several benefits, but one that hasn't been seen often is performance for large use cases. Existing ARM-powered computers usually take the form either of less powerful but cheaper (things like the PineBook Pro, the long-lived battery Windows on ARM machines, or ARM Chromebooks) or lots of cores for lots of parallel operations (every ARM-based server). Apple will probably be one of the first to produce consumer-level machines that aren't one of these two, but just because they can do it doesn't mean anyone else has a need to do so to stay current; if Apple's chips manage to produce the needed speed, it won't stop AMD's ones from doing so too. Unless you expect AMD and Intel to hit limits which just don't apply to ARM, why does it matter which companies switch to it? If you do predict a limit like this, what causes that limit and why?
Almost certainly the laptop processors will be as good or better. However, there's a reasonable argument that the phone-level processors won't really work well enough for laptop or desktop use cases. It depends what they're being asked to do, but some people use their laptops for more intensive tasks that people don't do on phones or tablets. I expect that Apple's laptop chips will be more powerful than their phone ones, but the question still remains: how will they go about it? They could just design similar cores to run under higher power to get performance improvements, which would probably be helpful, but they could also just try throwing more cores into the mix, which will only help some of the time. Depending on what they do, they could have a performance dip in laptops where they've stuck too close to the mobile chips. This probably isn't a major factor since they can quickly change their plans for the next iteration of machines, but if they make that mistake the first time, people might have less confidence.
If it can be disabled by physically covering it, then there's no way for it to get activated if I have closed it. That means someone can't spy on me through it, either by finding a sneaky way to disable a light, by there not being a light, or by my not noticing the light. Same reason some people really like physical killswitches for some components; we're paranoid people but at least with those we have complete confidence.
"Really? Guess who owns Thinkpads - not IBM - think Asia - think Red...."
That's the point being made. IBM doesn't make Thinkpads anymore, Lenovo does, so if IBM does something wrong, it's wrong to punish Lenovo for it. Substitute "HPE" for "IBM" and "HP" for "Lenovo" and you've got the point they were trying to get across.
I don't think all the features you mention are incompatible with a feature phone of today. If "keyboard" means "qwerty keyboard", it could be for sending SMS messages. The 4G or 5G could be for a tether connection. Bluetooth for an audio device. Admittedly, asking for Linux or Android is a little hard to understand; if they wanted something like the Motorola StarTac they shouldn't expect an OS that lets users develop and run sophisticated applications. It doesn't really matter though because, if the feature phones using a basic OS and primarily targeting 2G networks are insufficient, the lowest-end option with 4G connectivity is going to have that functionality anyway.
It really comes down to what tasks other than placing calls and messages are important. I really appreciate having things like navigation, meaning I need a smartphone with the kind of processing and internal storage that requires. If someone only wants some basic apps, a feature phone of today may actually have similar sets of features as a PDA of a decade ago.
You can get most of that, but you'll have to resign yourself to some restrictions. The primary one is the operating system involved. There will not be Linux. There mostly won't be Android either. What there will be is mostly going to be KaiOS. It technically has the Linux kernel and a lot of open source code from Firefox OS, but the top layer is closed source. It meets most of your desires:
"I don't want a camera - with one, two or three lenses": There will be one, it will be bad, you can ignore it.
"I don't want a 6.5 inch display": How about 2.4 or 2.8 inches (6.1 or 7.1 cm)? That's what you'll get there.
"I don't want a non-repairable,": Battery is replaceable, expect the rest to be hard to repair.
"I don't want limited use": Not sure what this means, but it has fewer features.
"₤600": Did you mean to use the Lira sign? ₤600 Turkish is €65 or so. Whatever you mean, the basic phone will be much cheaper than the one mentioned in this article..
"I just want a bloody phone: flip design,": Check.
"4/5G,": I don't think anyone has a 5G one out, but 4G is definitely available (some exceptions apply based on your country)
"keyboard,": I don't think so. Numeric keypad, but no qwerty ones as far as I know.
"a week's battery life on idle, five hours talk time,": Yes.
"a bright viewable screen": Not sure about this one.
"and proper way to sync to whatever I want to with a cable,": Depends what you want to be syncing. It can sync some types of data that way.
"Wi-Fi and Bluetooth,": Yes.
"Linux OS preferred,": Kernel only, no shell, not much else from it, apps are written using HTML and Javascript.
"Android grudgingly accepted.": No.
"And no 'apps' unless I want to install them myself.": They'll have basic ones, but they're easily ignored. Other apps are available, but not many and with few features.
Probably not what you're looking for, but it's almost certainly the closest you'll get for quite a while if ever.
There will be some improvements, and undoubtedly someone cares about each one of them, but for most people several will be unimportant. This device will have a faster processor. I don't need a faster processor, so not a factor for me. If you want the fastest available processor, you can't get it without paying something in this range. Similarly, the more expensive device probably has slightly faster internal flash, more cameras or better ones, a screen with a higher refresh rate, faster charging, and/or waterproofing. Of this list, the only one I care at all about is waterproofing (and I don't care that much) and you can get that at a lower price, so it does nothing for me. Still, if you care about most or all of the features listed above, maybe the more expensive device has benefits.
Mostly correct, but this is not always the case. The perfect example of this is a hypervisor. The program it runs is specifically another operating system, but the purpose of the hypervisor is to provide resources for the program and restrict it from affecting things that aren't in its virtual environment. Or, at a different level, operating systems for embedded devices often run one program but still restrict it from doing certain things. For example, an OS I'm using for a small device handles Bluetooth for the application running on it, and so as much as the program that is loaded may want to modify the memory reserved for Bluetooth protocol operations, the OS will not permit it to do so (at the moment, it alerts the developer on its own, kills the program, and loads another one allowing a debugger to be attached).
They're also used for different tasks nowadays. In decades past, normal users might do most of their work by logging into that from their basic terminals or terminal programs running on relatively weak computers. They'd do standard work on that system, which was also running the important software since the mainframe was the only large system available. Now, the mainframes are still used to run the large software projects (some of the time), but users usually don't have to log into that mainframe to read their corporate email or access intranet-type services. This means that a lot of users probably don't get accounts for the mainframe, and therefore the worries that an unprivileged user will find a way to attack it or allow someone else onto it to do the same are reduced. It doesn't make it perfect, but it does make it easier.
You are correct about that, but even the mostly secure Unix and other multi-user operating systems weren't designed for situations where one user would need very strong isolation from others. Random examples still exist of this; it's still possible, for example, to read the command line commands another user enters. This is usually not critical, but it's an example of one of the previous parts of the design where security really wasn't a factor. Other examples exist, such as when passwords were really stored everybody-readable or the ability to have a file exist with permissions inconsistent with those of its containing directory. These all are small and relatively unimportant, but compared to now when we're trying to limit processes' disk access inside a user account, they look a little anachronistic. The main reason that we don't care much about the few of these that remain is that multi-user systems are used less frequently; our personal machines usually only have one user account logged in at any time (assuming they even have more than one) and most other systems use VMs for small sets of people rather than one big system with open login for the whole institution.
There's another problem, which is that some of the old operating systems you mentioned or could mention were never subjected to the attack landscape we now force our operating systems to undergo. Early operating systems basically ran themselves and one program, so they didn't have to care about multiple programs running together. Even when they did implement this, the major concern was making sure those programs didn't crash or modify the state of each other, not securing one's operations against another one. Memory protection came along and we took steps to insulate one process's memory from another one, but again this was more to make code correctness easier rather than a primarily security-focused decision. Even in the late 90s, Windows gave every user local admin, with the concept of user accounts only serving to help organize things. Now we expect a secure system to do so many more things that make it harder. We expect a hypervisor to run VMs with total privacy between them (sometimes between them and the hypervisor). We expect that a multi-user operating system will only allow a user and root to access any of the resources of that user. We even expect that processes run by the same user will be sandboxed from some of the resources available unless a separate permission is granted, and it is the OS which has to provide for and ensure that. The operating systems we used to have were not only much smaller, but they also were not expected to provide the kind of security we need today.
This is a great point. The contest as they've set it up is seemingly well-designed to prioritize quantity over quality, and look at what they got last time. It would make a lot of sense for them to change the structure to actually help developers, meaning that really small PRs wouldn't count. Whoever sets up these rules isn't thinking hard enough about the purpose and benefit of what they're doing.
Malicious bots will find somewhere to host no matter what. As far as I know, DigitalOcean does respond to abuse requests and does take down people's servers when needed, but if malicious people find it easy enough to set up servers there, they'll still do it. Block those IP ranges and you'll find that others also attack. Block everywhere where attacks come from and you'll mostly eliminate the internet from accessing your site. I run a server there (almost all of its traffic is to provide services on request, it's not generating much), and if I scan my SSH and web logs, I find attack attempts coming from at least eight cloud providers and twenty non-cloud countries in the past week. Blocking all these ranges isn't a good answer to attacks because you'll at best reduce their quantity. Instead, make sure that not even a good attack will work and ignore the noise as the price of having a publicly-accessible system. If you're getting something like a denial of service attack, you have to worry about the source, but if you're getting automated login attempts, let them try a few times then ban their IP.
If you need that much detail, a system as you describe is easily implemented. Most people don't really need that though. If I'm trying to identify the cause for an unusually high electricity bill, I can probably figure it out from a usage-over-time thing. If it's the refrigerator as suggested below, my power usage will probably be rather flat at a higher level since that runs constantly. If it's temperature control, then my usage should correlate with the outside temperature. If it's a specific device, the spikes in the usage times tell me when I turned it on and for how long, so I can probably take a pretty good educated guess about what it is. Then I can turn it on for five particular minutes and reload the graph to confirm. I don't think there are many people who have concerns about a particular device starting to use an unusually high amount of power when it hasn't before. Given that, it's probably not worth very much to most people to install a device to catch this unlikely situation and take preventive action, especially as the hardware to do this will require time and money to assemble.
You could easily do this, but only by buying and powering extra hardware. From an environmental and cost standpoint, having the electricity provider which already knows some of this just tell you what they know is better. If you have devices you think will do something worrying, by all means set up this system to have realtime data and the ability to automate. If you just want to know what a spike was, you don't need to do that to every device in your house.
They're reviewing it anyway, so why not point out the problems? If they're hiding them from the public, that would be a problem, but they're not. They point out that there are many problems, and from the sound of it, the problems they have identified aren't exactly hidden. Even a very malicious version of Huawei can't get much out of that report other than that NCSC will read code sent to them and has some technical people in it. Meanwhile, if they actually changed some of this, it would mean that networks in the U.K. using Huawei infrastructure would be more secure.
Either location is capable of placing a call, so only one box needs reprogramming. It doesn't even have to be complex. Store the number in a queue (already done). Now hang up and remember the number exists. When the position of that number is low enough (probably one or two places away from getting answered), call them back and put them back into your normal hold system. The box that does the connection between people on hold and call center employees stays the same. The person at the other end doesn't need retraining. The only changes are an additional option in a menu and a function in a program which activates one of the lines and automatically calls out. Since most systems are built around a PBX package that already understands "call this number", it's not rocket science.
My concern is what happens when a person picks up. If I have the phone near me, it still has to inform me of the person so I can pick up. That could take five to ten seconds, and an impatient or busy person on the other end might decide that my silence means I abandoned the call. If this feature makes someone hang up on my call, it won't be very useful. What would be more useful is a function where the automatic system could call me back when a representative can be allocated to me. The benefits of this don't seem to have gotten through to most big companies I've called.
Oh, the options are definitely there, they just keep trying to change my mind.
What shipping option would you like? Free two-day shipping with Prime*? No. In that case, we'll do the long free shipping.
Are you sure about that? Look at this list of Prime benefits. No? Fine, onto the next step of checkout.
We know we already asked about shipping and this is the payment screen, but about that prime option...
Thank you for placing your order. Might you want to sign up for Prime?
Not for mine. I did that once and now they still push Prime, but they want me to pay for it and would be happy to add it to my bill right now. I only really use Amazon when I want something unusual that can't be found at more normal locations, so I never need them to deliver it right away. They don't seem to like it when users select the free shipping in two weeks option and will do anything they can to suggest that I want it on Friday and it's just a little more.
Hashing doesn't do for biometrics what it does for passwords. In the case where a password is matched, there is only one question: does this stream of bytes match the stream of bytes we saw last time? You can't do that with a fingerprint because the readers are imperfect. If you only ask whether you've seen this exact fingerprint before, you'll get no nearly all of the time. Instead, you have to match certain parts and allow for inaccuracy, rotation, dirt on the finger or scanner, etc.
There are two ways to do this. Option 1 is to keep a detailed model of the fingerprint and have an algorithm which matches components. If enough parts match, access is granted. This doesn't work with hashes because you can't match loop A from image to loop B from model without being able to look at the original model. The second way does support hashing: you write an algorithm which restricts what kind of things you're reading for and turns that into a lossy compressed model. You might have to create a bunch of those, but by restricting the things you match on, you can increase your chances of a match high enough that you can afford to hash and delete your original model. Even if you do that, the model you've hashed can be used for tracking because it's relatively easy to create theoretical fingerprints and test them. It's quite similar to passwords, which can also be tested quickly. The difference is that a salted hash of a password is intended to delay someone trying to crack them so the breech can be detected and the passwords reset. You can't reset a fingerprint, so if there's ever a breech, the people with the database now have something they can crack at their leisure.
Or they could let people switch the community function back on. If it's such a big problem, let them make it disabled by default, but leave the feature available. Taking it out without giving an alternative just messes up the workflow for anyone who used to like it without providing any sort of replacement.
I think their theory is that, while you're trying to find something with which to knock it out of the air, it's sending your picture off to the cloud and nearby police. This picture will be used by the police to arrest someone who looks a little like you or maybe nothing like you and by Amazon to recommend new tools for breaking and entering when you sign into your Amazon account.
I do kind of want a small drone; it's in that category of things I don't really know what to do with but there must be something useful because they're cool. I wouldn't buy something like this for the life of me because the drone is only useful [fun] if I can program it to fly exactly how I direct, photograph what I tell it to, and deliver the video to the system I define and no others. I have no confidence that Amazon would let me do any of this. Worse, from their privacy record, I expect my data to be stored forever with dubious access control and that both my past footage and the drone itself will be instantly available to police without any justification whatsoever.
"seems like it's disabled someservice, but not actually disabling it. "
"At the very least systemctl should throw an error giving some clue as to WHY it is not disabling a service."
I believe the initial complaint is about what it does do when the service exists, namely it disables it. Disabling it means that it removes the service's links which determine whether that service will be started under conditions like a reboot or a change in level. It doesn't stop a service. The reason I think that's the complaint is the mention of high memory usage; I'm guessing the problem here is that the disabled service is still running because systemd hasn't had cause to restart services. The command to stop a service is "systemctl stop someservice" although you can combine them by specifying disable with --now. I have retrieved this information from systemctl's man page which includes a warning that disable doesn't mean stop.
Now it may be argued that a command called disable should both disable the service from being automatically started and stop it now, but the documentation is clear that it doesn't do that. I am not here to praise systemd; I don't much care whether you like it or hate it. There are real bugs in it which are annoying and I'd like to see patched. Still, if the problem you have is what commands look like, you can't really call that a bug. Disable disables and stop stops. Want to create a disablestop or modify disable? Fine with me, but file it under changes and not bug fixes.
"Assuming this is accurate... Is this how Windows goes ARM?"
No, Windows already went ARM. You can buy a computer with it on if you want. They did this by changing their compiler target to ARM and then fixing broken things until they got tired of that and it seemed to work fine. Linux was not the kernel at that time and it isn't at all proven that it will ever be.
I think the strategy is clear and far from the prediction made. Windows is the way Microsoft stays relevant to its business clients and OEMs. They're not going to do a bunch of work to get Linux running old Windows code through an emulation layer; it's cheaper to keep supporting Windows, much less likely to break, and it keeps a revenue stream headed their way. Meanwhile, they can't just ignore that legacy code because that's a major reason businesses provide for staying with Windows.
The Edge on Linux part makes total sense to me too. Another major revenue generator for Microsoft is their Office subscriptions, which run through a browser. By porting Edge to Linux, which was probably pretty easy as Chromium already runs on Linux, they make sure that they'll always be able to run Office for Linux users; even if Firefox and normal Chromium make changes that break something MS needs, they can keep it running through Edge. This makes Office more of a cross-platform tool and ensures user satisfaction for not much work.
"Games today and historically have always been the activity that taxes the hardware to the max. CPU, GPU and RAM are left choking and sometimes even the disk gets its share (e.g. badly programmed loading screens)."
That was not the point of the person you're talking about. They argued that games were easier to emulate than other software, but not because they're low on resource usage. Their argument is that games avoid using a lot of OS-provided libraries. Their examples were the GUI layers, which games often reimplement with their own graphics engines. I haven't ever developed games so I can't comment on whether what they say is true, but please argue against it if you are going to based on the argument made.
There is a very big risk in giving too much access, but there is also a risk in giving too little. The risk usually shows itself in people doing extra work to get around the restrictions. Here's a basic story of a situation that is all too common:
I once did a short job writing some code with a small team who all started at the same time. After figuring out the specs of the task and how development would work, we decided we needed a database server to store data needed for development. Local IT agreed and quickly provided us a box to run that on. It was set up the same day. Then we tried to set up a repo on the default code system. That took longer because our accounts didn't have permissions to do anything with it and it was run by a larger site of the company. We sent email there, waited several hours, were told that someone else handles this, sent email to them, waited until the next day, got an email saying we needed to prove our need for the permission, brought in our managers, waited a few hours, got an email right before we left that the permission was granted, discovered that we now had read but not write or create, sent another email, waited until the next day, asked again, finally got write permission and they created a repo for us, and finally we could exchange code. During this annoying process, we had frequently discussed using our database server to run a basic git server. We didn't, but we considered it because we would be more productive if we could use a version control system; our only other option would have been to email code around, which wouldn't have been very secure either. Later in this job, we wanted to send a very large file containing data to another team. They asked us to place this file (approximately 35 GB) in our git repo. Why? They didn't have anything else to which both teams had access and they didn't want to waste days to get one.
The same can happen with other types of jobs. If people need (or think they need) to have certain kinds of data or take certain kinds of actions, they'll do what they have to to do this. If security is slow to respond to this kind of access request, fails to consider whether people actually need things, or doesn't provide necessary tools, they run the risk that users will try to circumvent them. Based on the way security is run, some of the more dangerous ways this can show itself may be caught and more egregious offenses can be disciplined. Even if that's the case, the landscape of threats is probably worse and productivity will be impaired. These concerns are probably most relevant to small companies. Large ones have the resources to have a dedicated security team and lots of systems so people can quickly be given access to things they need. Smaller companies probably put all this on IT. If IT isn't sufficiently fast or organized about granting permissions, expect users to take the route of less effort which will cause us to have to take the route of damage control.
Computers checking spelling was never a general scandal. You could undoubtedly find people who thought that, if you needed it, you were stupid then. You can almost certainly find such people now as well. If I traveled back in time to 1990 and denounced you as a terrible user of a spell checker, nobody would care. Facial recognition isn't a spell checker. A spell checker might mean that people don't learn to spell as well. A facial recognition system means lots of false arrests and boundless opportunities for abuse.
You are correct there. If the half in, half out approach is ever implemented, it will probably be from an accountant's pen. I predict that it will be against the groans of most of the workers though. I don't agree about family friendly, as neither approach seems to be convenient from that perspective. Working from home when children are also at home seems to irritate those of my colleagues who have children, and it doesn't really help add flexibility if the parent needs to go help the children for a long period. This is especially true if the schedule for when to go to the office is firm, as in the parent doesn't have the choice to work from home on the day they will have the most obligations to help their children.
My objections may be rooted in my dislike for a large, disorganized open plan office, especially one with hotdesking. I think, however, that my dislike is not quite unique. I can easily organize my affairs if I'm to be working from home forever or for a long period; I have done so successfully this time. Having no children helps with this, but even if I did have to set up a better environment for working while being near children, I could do it with enough time. I can also easily structure routines around going to an office. Having to do both and frequently switch between them would annoy me a lot.
I'm not sure your idea will work. It sounds unpleasant to me, at least. In my opinion, the benefits of an office are for better coordination between team members, the benefits of working from home are convenience and extra time, and the benefits to trying to improvise one or both of those are few. Having a team in an office where people know where all the people are makes it easy to organically ask questions and meet in person, so if you have small hot-desking offices, you lose most of that. People won't necessarily know whether the people they want are there, it's not convenient to meet in a big open plan area, all that. Similarly, trying to create a team geographically by home address is a recipe for chaos (or a license to print money for someone who writes the software to do it for you).
This solution also loses most of the benefits of working from home. If people work from home all the time, they don't have to be in a suburban area or near something specific, meaning it's easier to hire people from a greater distance and to allow existing employees to move without disrupting their careers. If people still have to work from home but they have to stay near to where the office used to be, that benefit is lost. In general, I think most companies should plan for each employee to primarily work from home or primarily work in an office rather than making them alternate between the two.
It's not usually speed that's important, rather reliability and latency. Copper lines don't have to be unreliable or laggy, but since a lot of them are old, the stereotype is that they fail much more often than fiber. It's basically true, as most times when new cabling is installed it's more modern and more fibery. Depending on the quality of service, it may be that the internet has fine speed, but it goes down when needed and/or adds enough latency that attempting a call means long periods of silence.
"Either Facebook is doing a better job at stopping it, people are becoming smarter about falling for conspiracy theories, or Facebook isn't the medium being leveraged this time around."
Or maybe one of these alternatives:
1. You are not getting the dodgy content sent to you because Facebook's targeting has identified you as not falling for it.
2. You don't connect as much with the people likely to believe it, so people you know aren't sharing it.
3. The content being pushed is of better quality so you aren't correctly identifying it for what it is.
4. People are pushing dodgy content that really comes from the attributed sources, so other dodgy content looks more normal because the overall quality is worse.
5. You read less on Facebook than you did before.
6. Foreign governments found the last attempt wasn't as successful as other ideas they've had, so they're not doing it as much.
Just because you haven't seen it doesn't mean that it isn't there, and since I don't know what you have read on Facebook or what you read before, I can't tell you exactly why it's different. Before jumping to the conclusion that Facebook's doing something or the scammers have moved elsewhere, consider the alternatives.
"1. Why does the Android version, at least, refuse to run without location services running?"
Android's Bluetooth permissions are a little strange. Fine control of Bluetooth can allow an app to perform some location tracking assuming known devices are nearby, so apps aren't allowed to do it unless they have fine location permission. Unfortunately, enabling this not only allows the app to perform the detailed scans over Bluetooth but also enables them to gather information from the phone's location chips and from WiFi scanning. Google evidently didn't think it was worth splitting this permission into parts. IOS does this differently and lumps that into the Bluetooth permission, so that app is not going to ask while Android's is; again a place where Apple could split up permissions but didn't. The source being available, it seems unlikely that the location is being collected or used in any way. However, the usual conditions apply to that statement, including that the data is now technically available and I have not verified that the source matches the app that is downloaded.
To attempt to be fair to phones, it's not three-year-old ones that can't run this. The latest Apple device not to support it is the iPhone 6, released in 2014. Android 5.1 came out in March and April of 2015. I have to give more credit to Apple here, as the iPhone which doesn't support it got four OS releases before getting dropped while most Android 5 devices probably didn't get an update at all, but in each case we're dealing with devices four years old. In my opinion, most of these could continue to run a more up-to-date OS and they should have gotten it, but that's an issue for another discussion.
I wonder if this Connect Pro option will be available for small businesses with only a few devices, or in other words, just people. Having scanned their current site, it's low on specs about how the service works and what it costs, but I wonder if it will allow the use of devices without the typical charges for connection from mobile providers. I've previously considered trying to use mobile connectivity for systems that might need it occasionally, but each time I've been dissuaded because the pricing from providers makes the idea less tenable. I'm happy to pay for usage, but what I'd rather not do is pay a bill just to keep a line open even when it's not getting used at all for long periods. Here's hoping that they'll update the site with more details later and this really allows people to have multiple lines without paying extortionate charges for things that don't get used.
It depends. If the article's statement is the way I read it, these switches only allow you to switch between preset modes, not arbitrary ones. I have a keyboard here which allowed programming the keys through a program that is almost exactly how you described them. Proprietary, opaque, weird layout, translation to English from Martian, Windows only. I haven't had to deal with that program for quite a while though because I set up all the modes I wanted, mapped them to start up with a certain keypress, and moved the keyboard back to my main machine. Now I can activate any layout, and they're the ones I specified rather than whatever the manufacturer came up with.
At this point, we get into the discussion of what capitalism really is. In the most basic sense, you give me that and I give you money and you take the money to whoever's got the thing you want, there's been a market economy for millennia. There has been very ancient money from 2000 B.C.E. and likely there was money before that. Other concepts that play into capitalism are much newer. Corporations which exist as a shared operation owned in part by many people, as opposed to the organized operations of some powerful people beholden to nobody, is maybe four to five centuries old. Organized stock exchanges are from the late 18th century C.E. Governmental regulations promoting competition are really new, having started around 1850 or so. Which of these four things are central to capitalism? Which ridiculously obvious things did I forget to mention? Everyone is going to have different ideas, so everyone will have different ages.
I think one thing we can point to that was necessary for what we call capitalism is the removal of a government-imposed monopoly or prohibition. This took several forms. In the middle ages, there were guilds who got their permission to restrict who could do what job from some government they viewed as worthy of dictating that. Later, there were laws about what people were allowed to spend money on and how much they could be paid, laws intentionally written to prevent people in lower castes from doing things. Then there were the colonial monopolies where someone got the rights to most of the economic activity in some chunk of the world in return for going there and claiming the rights to own that chunk for the monarch involved. Slavery and a ethnic caste system were similar in that people were born into a situation which the law did not permit them to leave. When this craze ended is a little tricky to estimate, as we still have some government-supported monopolies today, but I think that's a useful point to use when establishing when modern capitalism really became what we think about. At least that's my opinion on how we go about finding our answer.
"And finally the whole programming thing: if people did not learn by practice and repetition then they would not need a computer: they could just read the description of the programming language and that would be enough. And they would also never get better: you'd teach them how to program (from a book) at which point they would be the best programmers they could ever be."
That's not really what I argued. In fact, it's close to the opposite of what I've argued. When you learn programming, there's relatively little repetition. Once you learn what a function is and how to make a recursive one, you don't need to learn it again. You do need to use it. The people who most espouse repetition will do that by making people write twenty recursive functions, but that's not really efficient. Instead, have them write a few recursive functions until they understand what recursion means. Then give them actual problems where recursion can solve the problem and see how they deal with it. It's sort of repetitive in the sense that they're using things they learned before, but it's new tasks which don't take the form of a litany of exercises. This is better than the exercise method because it makes the student think through the solution, whereas exercises already tell them what the solution will be and they just have to do implementation steps. Those teachers who use repetition in a way I dislike tend to focus on basic things and force a "really firm understanding" of those things. Unfortunately, in my experience, that translates as a "really good understanding of how to answer the test question". It results in people using similar code to things they've seen before without understanding why they're doing it; it worked before, so it will work here, and it probably does, but that's because the problem they're working on is limited and performance isn't critical.
Practice isn't repetition and repetition isn't practice. You can repeat an action and memorize results without getting better at it if you're repeating something which doesn't require enough lateral thinking. You can practice by doing a lot of different things, therefore understanding multiple options for completing a task, which involves doing a similar thing but relatively little repetition.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
