A good thing...
> Also, Lens does not use facial recognition, making it not very useful for identifying people.
You make it sound like that's a bad thing!
132 publicly visible posts • joined 30 Jun 2015
But saying that you "maintain sufficient situational awareness to know if I must indicate" means that you consider yourself to be absolutely infallible, never going to make a mistake, never going to have missed something, never going to have an absolute idiot elsewhere do something silly, etc.
... which is an incredibly dangerous assumption to make.
I do remember my driving instructor many many years ago saying the same thing - "why are you indicating? Who are you indicating to?". But let me put it another way... What is the HARM in indicating? If there is a 0.000001% chance that doing so avoids an accident then surely it's worth doing unless you can demonstrate a greater chance that it causes harm?
Sure, there's a possibility that you forget to cancel the indicator (on that rare time when you indicated but didn't need to). Sure that's, annoying to other users, but it's not really causing harm. So what other harm can be caused, if you would otherwise have indicated if there was definitely a reason to?
@Missing Semicolon, have an upvote. You'd have more if I could give more.
I'm gobsmacked that anyone can genuinely say "And that's all you need". Too many developers think that it's all about them, all about the software. They have no regard for the other aspects that any sensible business needs to plan for. Like when does the training material need to get worked on? When can the sales people start selling it? When can the detailed planning start for the next project? What is the roadmap for the next 12 months? Do we need to employ more, or less, developers to handle the workload?
Any software development team or project manager who is unable to give estimates of how long it will take is quite simply failing.
@An_Old_Dog
What a complete load of rubbish. If someone asked you how long it takes to drive from Manchester to London, you'd say something like 4.5 hours. You wouldn't say, well it depends if you go via Land's End, or it depends if you have a medical emergency on the way and end up in hospital for a month before completing the journey, or that you can't say because they've not said whether they plan on driving at 1mph or 70mph.
Sure you might then go an caveat your estimate by saying there are some plausible variables which may affect things, and - if you were being helpful - you'd say that they might want to factor in perhaps an additional hour or so for some margin.
Your comment sums up everything that is wrong about the software development industry, and some of what is wrong about agile, Nobody likes the hard, detailed planning which is needed to come up with decent estimates, or the measurement needed to record how previous developments went according to their plan. Developers certainly don't want to do that (I'm generalising here), they want to start writing code at the very earliest opportunity, which is partly why agile is so popular. Of course there are unknowns, and variables which will affect things. And there are processes to accommodate and manage those. But jumping on the very first excuse and using that as to why it's impossible to come up with any estimate is ridiculous. So you've not been given all the requirements? Then estimate the ones you have. Estimate what your best guess is for the ones you don't know and explain what your margin of error is.
Can you name any other industry where your response would be considered acceptable? If you ask a builder how long it will take to add an extension to your house, you wouldn't expect him to say something along the lines of what you've put. And while I accept that many (far too many) software projects or indeed any form of engineering projects overrun, even that is no excuse for not having the plan. After all, if there is no plan, you can't say that you've overrun (hmm, and again that's another reason agile is popular), and if there is no plan, you can't improve on your estimation techniques for the next project.
But because it's hard, that doesn't mean it shouldn't be done and because it's hard, that doesn't mean that management shouldn't get told estimates.
I fail to understand your points above.
"Software is elastic"? So what? If you copy a poorly designed, bug-ridden piece of software a billion times, you now have a billion copies of a poorly designed, bug-ridden piece of software.
"Software can be delivered immediately"? If you're trying to use that as an excuse for shipping bug-ridden software ("hey, we can immediate deliver a fix") then it's a poor reason.
"Software is easy(ish) to revise (even completely)"? I disagree. I've seen many fundamental flaws in software that go right back to original design decisions and which to "fix" would basically mean starting again. I've seen small pieces of software developed in a few weeks require what would appear to be a minor bug fix which takes a significant percentage of the original development time to retrofit.
The costs of mistakes in software can be enormous. If you've got a large development team and pick up a fundamental flaw in the latter stages of development, the cost can be huge to fix. If it's discovered post-deployment then even more so (see Horizon). Ditto for "In software you can experiment for little cost".
Software Engineering is still engineering. May not be the same as other forms of engineering but then mechanical engineering isn't the same as electrical engineering. In general terms, if you're building a large, time-consuming, complex "thing" then the fundamentals of engineering apply.
Agree with the above. Moreover, if you took an average bunch of developers and ask them what they disliked about software development and then wrote up a methodology that didn't do any of those things, you'd pretty much have the Agile methodology. Developers don't like documenting things - so that's out. Working to specs - nope. Detailed estimation for the development? No, let's just focus on the next two weeks.
Agile is a methodology written by developers for developers. And unfortunately developers very often lose sight of the fact that the software is not the be-all-and-end-all, it's the use of the software, the purpose of the software, the benefit of the software that should be the focus - i.e. what the software does not how it was built that matters.
It's fine for certain types of projects. And absolutely wrong for others including, as a general broad-brush categorisation, most large business or Government type of applications. If you're a startup trying to launch your minimum viable product and then rapidly iterate, then fine, use Agile. If you're developing an ERP system or a finance/accounting/banking system, you'd better have a detailed spec, timescales, cost estimates, budgets and a clear idea of how to go about all of it.
The people who shout "Agile" from the rooftops have typically only experienced those projects that it (might be) good for and yet think that their experience encompasses all. Software development covers a huge spectrum amd in the same way that you wouldn't necessarily trust someone who can build a wall to build you a house, or trust someone who can build a house to build a skyscraper, what works or is appropriate in one place is not necessarily appropriate for another.
... coming from a software developer with 40+ years plus of bespoke development experience with a Computer Science degree before that. I've read, been taught, learned and used many different methodologies over those years, most of which promise to fix the failings of the previous one. Agile may have lasted more than some of the others, but I have no doubt that there will be another one along soon...
>> What you send is some kind of encrypted version of your password
That's not really true for 99% of all websites, at least in the way that I think you mean. Those 99% are sending your password as you typed it to the remote server although hopefully over an (encrypted) HTTPS connection. Yes, the server should then hash (not encrypt) the received password and compare against the hashed version stored in its database, but the server most certainly receives your password in the vast majority of any website (Google being an exception).
If it was as you said, then the hashing mechanism along with the salt would be visible for all to see in the client's browser making a rather large security issue. HTTPS provides sufficient encryption of your password to make it fine to send as you typed. After all, if someone was able to intercept and somehow decode your HTTPS traffic, your "encrypted version" of your password could be easily enough reverse engineered given that the encyption mechanism would be known from the front-end and thus you've not really added any additional security over the fact that your sending it over an encrypted connection.
(The above is somewhat simplistic, there are mechanisms whereby the server could pass randomly generated and time limited salt to the browser to use but that greatly complicates matters with no appreciable change to the security level.)
I believe Fogerty won ths court case didn't he? And that he then succesffuly countersued?
Furthermore the two cases against him followed the release of Centerfield were on more specific terms that just "sounds too much like CCR" - one was because one of the tracks was considered to be a personal slanderous attack on the then-owner of the rights to his previous songs and the second was on the basis that a chorus was the same (not just "sounds like") that from a previous CCR song.
For those who are using the Start Menu and typing a few characters in, can I recommend the "PowerToys Run" module from the Microsoft PowerToys.
See https://learn.microsoft.com/en-gb/windows/powertoys/run
(If anyone used to use Launchy then this is a more-or-less direct replacement/upgrade).
I have to disagree with most of what you've said.
Almost all discussion about "freedom of speech" ends up back with the American Constitution - or else you're talking purely philosophically with no definitive written word to make it anything other than a philosphical or moral debate.
As such it most certainly does relate to the government - then as to now - as it's the government that has the ability to severly restrict your personal freedoms. So no, an advertiser can not dictate what I can say in public and a government mustn't be allowed to - there is a significant different there.
You seem to conflating that difference with the ability of an advertiser to put financial pressure on a business - which is a completely different issue. An advertiser is not stating what is or isn't OK. They're saying that their money may get withdrawn and that the business may suffer, but that business is still free to do what they want. And your comment about businesses "funded by member subscription" is also far off the mark. Unless said business has a consitution requiring votes from the membership, said business is perfectly entitled to do what they want and as to whether "the majority" then walk away, that doesn't prevent that business from continuing as they please and who knows, maybe the minority is still sufficient to remain in business.
Came here to say the same thing - in response to the brief discussion about direct traffic. RSS for the win! But sadly it appears to be less and less visible (or indeed being remove) on more and more sites.
But if you have a site which publishes articles (whether a news site, or a blog,or a newsletter) and it doesn't offer an RSS feed, I'm unlikely to revisit.
In summary:
1. Lawyers typed some search request into a website
2. Website came back with some "results"
3. Lawyers took said results verbatim without checking anything
Their major failing was at step 3 and how that step was arrived at (whether AI or a *cough* reputable search engine) is pretty much irrelevant to their failing.
I agree with the above comments. Having been involved in some quite big corporate system developments, all too often companies state their requirements based on what they do. Which leads to the inability to use any off-the-shelf software as-is because it doesn't do things exactly how the company has always done things.
The answer should be to challenge how things have been done and consider whether it would be prudent to change how things are done to how the software wants things to be done. Some people will claim heresy at this point but the reality is that the bespoke development (including customisation/ehnahcement of off the shelf packages) is typically many times more complex than initially thought (often because the people who are in charge of using the system are not skilled/experienced in explaining and detailing the requirements and further more, you're left with a highly customised package, more or less beholden to continuing to use whoever the developers were who did the modifications because only they understand it, and all leading to a cost hugely more over the lifetime of the software than simply using the software off the shelf and changing one's practices accordingly.
Bespoke software is costly - from requirements capture to ongoing support. Off-the-shelf software is cheaper in the short-term and the long-term with lower maintenance & support costs and the possibility of upgrades over time.
For what should be relatively standard processes such as HR & Finance, organisations should really consider whether they have to have custom software or whether they should change their practices to conform to the software.
Of course the real failure here was on the part of the writers of the malware who, having infected 3CX software, failed to register their malware with Virus Total. If they had followed that procedure then 3CX could have easily confirmed that their software was indeed malware-infested and...
... oh wait, hang on....
>>Read the detail of the proposal again. We're talking here about a pretty narrow set of circumstances that no court of law would ever consider to cover what you're talking about.
I'm unclear from what you say as to why you seem to imply that Steve down the road has nothing to worry about. If Steve has opened an online forum then he is absolutely 100% within the scope of the legislation. And to parrot your statement, go read the legislation and it's very clear in taht regard.
Whether he may find himself in court will then be wholly dependent on what takes place in that forum. Yes, if it's all about wrongdoings of government then he's probably going to be OK. But if other matters start to be discussed, he might not sleep so well at night.
Re the supposed Fauci "lie".
I will bet my house that most people who claim he "lied" are basing this on a few-second video clip that is prevalent on... oh yes, Twitter.
I saw that clip. And I thought to myself,"that's a bit odd". And I questioned whether it might have been taken out-ot-context. I questioned whether it might have in fact been doctored (because... you know... that can happen).
So I did what any sensible, logical person would do who wants to ascertain facts.I found the transcript of the interview. Took me all of perhaps two seconds, but to save people time: https://www.msnbc.com/transcripts/transcript-all-chris-hayes-5-17-21-n1267740
And you know what? OMG he did say that!!!!
But you know what he also said in that interview? Try these quotes:
- "Breakthrough infections mean, you have been vaccinated, but you still get infected."
- "...even if you do get a breakthrough infection, when you`re vaccinated, the chances of you are transmitting it to someone else is exceedingly low."
So you know what? If he is "a liar" he's a shockingly bad one as he admitted a few seconds earlier in that same interview that, *shock horror*, you can still get infected after being vaccinated.
Was it a poor choice of words he used? Possibly. Is that quote out of context? Somewhat. Could he have been clearer? Yes.
But to call him a liar is simply ludicrous.
You use the word "haters" but I don't see any justification for the use of that word. Lots of people here are "critics" of Musk and in my opinion that's a fair stance to take.
Those that are critical of him are typically basing their opinions not on the last 2 seconds or even on just his post-buyout actions but on many years of his behaviour, comments and conduct.
In my opinion, he's a very unpleasant person. I certainly don't hate him but I will certainly criticise numerous of his activities with - again, in my opinion, but it would seem with agreement of many others - very good evidence to support me.
Brute forcing is most certainly an issue in either of your two solutions. As others have said, if you're locking the account, you've introduced an avenue for a denial of service attack and run the risk of losing all your users because they can't log in. If you do it on a backing-off approach (your second solution) then all I need to do is to cycle through my 000's of potential usernames and by the time I get back to the first, I've spent 5 seconds.
If you take into account the IP address before blocking/locking, you're not defending against botnets.
If you don't use (or enforce) long complex passwords, you're open to cracking. Salting passwords is no great defence if you suffer a breach and enough people have short passwords.
So yes, use of extra long complex passwords does indeed massively improve security. I can pretty much guarantee that my 30-char password is safe providing that the site implements what should be consider basic security even in the event of their database getting breached. I could not say the same to any degree of certainty if my password was say 8 characters no matter how complex it was.
>> "... conflating natural human beings... with business... corporations are... not natural persons"
In law - on both sides of the pond - a corporation/company is indeed a legal person and as such is far from "a legal fiction". Which makes perfect sense given that people and companies can both be libelled/defamed, sued, sign contracts, etc.
Completely agree with the above. Furthermore, I'd point out the ludicrous statement from the ruling that "... the platforms argue... a corporation's unenumerated right to muzzle speech."
As you point out the First Amendment does indeed prevent a Government from muzzling an individual. But a corporation (platform) removing comment from an individual in no way "muzles" speech - said individual is perfectly entitled to take their comment and post, or speak, or otherwise publish that anywhere else they want (that will allow them).
While I accept that a major platform banning comment does remove a large proportion of the potential audience, it is ridiculous to equate that to being muzzled.
No it doesn't mean you have to use 2FA.
Basic Auth is basically (pun intended) sending the username & password with every request.
Alternatives to Basic Auth would include schemes such as OAuth whereby a tme-limited token is used once the username & password have been authenticated.
I disagree about the possible cost of an agreed settlement.
As of today, Twitter has a capitalisation of circa $33B. Musk offered $44B.
Simplistically (very simplistically), if Musk handed over $11B to Twitter, the share price would rise to the level giving a capitalisation of what he valued the company at. Any investors then have the opportunity to sell at the price he offered and consequently there would be no case for a shareholder lawsuit.
Of course, markets don't work in such precise definable ways, so it may well take more than $11B. But I'd expect something between $11B-$20B to suffice.
Not exactly small change even for Musk (although I image the cost to his ego in settling would hurt him more), but significantly cheaper than $44B.
Except as has been proven many times over, humans are **REALLY** bad at a) looking at the URL and b) determining whether it is valid.
From mobile browsers hiding the URL, to non-Western characters in the domain to make it look right, to variations on the domain name (twilio-support.com, login-twilio.com, etc.), anyone, whether company or user, relying on reading the URL for their security is going to hit trouble.
See https://www.troyhunt.com/humans-are-bad-at-urls-and-fonts-dont-matter/ for a good write-up with examples.
Define "disastrous".
If "large numbers of other code" was making regular use, one would certainly hope that those responsible for that other code had measures in place to guard against exactly this potential scenario. Or the scenario that the original author takes down their own repository. Or various other scenarios.
Because if they don't take those measures then all bets are off and frankly GitLab is only one of a number of problems you now have,
I find it hard to believe - or understand - the official explanation. The robot had just made its move and the human (child) supposedly played too quickly? What possible reason is there for the robot to grab the human's finger? Having made its move, it simply needed to retract its arm and wait to recognise the human having made their move. If anything, the human playing too quickly might conceivably make the robot not realise the human's move had been made, but certainly not to go all out into vindictive mode.
Be worried.... very worried...
These versions of Sage perform an online licence check every few days. That code doesn't (currently) support TLS 1.2 and Sage are shutting down their licence check server which supports TLS 1.0/1.1. Hence Sage won't keep running because it's got nothing to talk to to confirm the licence validity.
Whilst no-one should expect support indefinitely for a "perpetual" licence, equally no-one should expect a vendor to be able to "remotely" kill-off such a perpetual licence. It's one thing for software to not work on a new O/S, but all other things being equal, you'd expect that software to keep working on the same environment.
I can appreciate that Sage might not want to patch the software to support TLS 1.2 - that can be tricky. But patching the code to disable the licence check completely (or to ignore any failed attempt to validate the licence) should be pretty trivial to do. Sure you run the risk of the software now being pirated, but we're talking about accounting software here...
What a ridiculous statement.
No-one is saying, or expecting, that every electronic device will have a USB C connector from when this legislation kicks in until the end of time.
Right now, there's a very good case to be made for standardising. Right now, there's a very good case to be made for selecting USB C as that standard.
If - in five years time - there's something better that could be used, the EU would be quite justified in saying that from a subsequent point in time, devices should now use that as a standard.
The fact that all those USB C adaptors are now redundant is a) false - as they'll only redundant once the device they are used for are redundant and b) a far better position than not having any standard at all and everyone using a multitude of different adaptors.
I have to strongly disagree with your opening statement.
Just about any form of security hampers usability almost by definition. Security is something that gets in your way of doing something by making you prove who you are before letting you do that thing.
As such every there is ALWAYS a trade-off between security and usability and as such there is no one level of security that is appropriate for everything. It depends on your analysis of the risks and the level of inconvenience/security you deem appropriate.
Logging in to The Register to post a message could be made more secure by implementing 2FA for example. But there's a usability trade-off there is to whether that is appropriate.
I think I know where you got those numbers from, but if I'm correct, then you seriously need to review the countries you believe are in the EU! There's a lot more than "5k or fewer for other EU nationals" including 5K Spanish, 5K Romanian, 3K Greek for starters.
Amounts to around 5.4% of the total NHS staff but a greater proportion of medical staff - 8.7% of doctors.
And that's as of March 2021 by when many EU NHS workers had left. Wouldn't have said that was insignificant.
See https://commonslibrary.parliament.uk/research-briefings/cbp-7783/
What a ridiculous statement. Given that the majority of the "all-time high prices" have happened in the last two or so years, your arbitrary timeframe of having held bitcoin for four years nicely - for you - eliminates all those who bought at those prices in the last two years from your consideration.
Come back in two years time and let's see what's happened then. Not saying you wont still be right, but show me any single share price chart and I can find an arbitrary but retrospectively-looking statement of how you couldn't fail to have lost money - if only along the lines of "buy in [insert-random-month-here] and sell in [insert-other-random-month-here]".
Intel are being sued NOT because there was a problem ("bug", "exploit", call it what you will).
They are being sued because - allegedly - they knew there was a problem and failed to properly disclose it thus misleading various categories of people (consumers and shareholders principally).If that is true - and if they do not have a valid defence - then it's absolutely right for them to get sued. That's what the legal system is there for.
With respect, it's more probable (in terms of how the majority of accounts are taken over) that your friend had a weak password... where "weak" means a password that *someone* else has used before on *some* service and is now being used to brute force attack other services. Given that almost by definition your <my_name>@<my_isp>.com email address will be your logon name to <my_isp>'s webmail interface, a list of valid account names for <my_isp> is easily obtained and so you've got all you need, paired with a list of common/known passwords, to start a brute force attack.
>> "There might be some short term price differentials whilst the market adjusts to what ever the true value of payment processing really is for an app store item"
And therein lies the problem... there is no market because Apple prevent alternatives. If Epic were allowed their way, yes they *might* decide that whatever the price they were charging through the App Store was what they'd charge outside - and they'd retain the 30% that Apple would have taken. But they'd also be free to charge the amount less the 30%. Competing App Stores might decide to charge less than 30%.
That's what a free-market economy says would happen and that's what we can know for sure because Apple doesn't allow it.
I make no view here as to the rights or wrongs of Apple... just saying that your comment about "Pricing does not work that way" only applies where you have a (relatively) open and free market.
Came here to say more or less the same. Withouut using such colourful language, I would have some measure of respect for the first company that instead says:
"... for the inconvenience this has caused".
Using the words "any" and "might" basically says you don't believe it caused anyone any inconvenience but IF it did, then you're sorry.
It really would cost the company nothing to use the words "the" and "has" instead of those two words and it would come across at least as being a smidgeon more genuine.
No. An OS may consist of nothing more than a kernel.
The earliest computers most certainly had an operating system. But they didn't have - by any contemporary meaning - a shell or a collection of system utilities.
The "operating" word in an OS refers to the operating *of the hardware". It does not mean the operating *by the user*. An OS is the software that operates the hardware.
After all, an embedded OS may well have no shell or "system utilities".
An OS may typically contain a kernel, a shell, and other applications/utilities. But to suggest that a kernel on it's own is not an OS is just factually - historically and currently - false.
Cobblers!
My pet peeve is people talking about an OS when they don't actually mean the OS, they mean the applications running on the OS. Bash - for example - has nothing to with the OS. It's an application. I can run Bash on my Windows PC, but that doesn't make it Linux.
The OS is - or should be - the kernel, the internal nuts and bolts, with next-to-no (or even just 'no') "things that a user can run". Because things that a user can run can - practically by definition - be replaced with "other things a user can run" and if you replace one such thing with another, that would obviously *not* mean you're now running a different OS.