> I would much rather be fired from Facebook than Twitter.
Also, it was all over the news that Twitter fired probably based on performance (lines of code, yeah, I know). Wondering if this will make it difficult for the twitter folks to get hired compared to those from FB.
That's not firing on performance, though, it's just nonsense. Some layoffs are _actually_ performance-based, but assuming the thing about the twitter lines of code is true, that's firing based on leadership incompetence, and it would hardly count against people (unless they're applying to IBM in the 1980s, which actually _did_ use line counts for performance management...)
That LOC thing with Twitter is just a big rumor. There are a lot of dumb rumors about Twitter and Musk floating around. Don’t believe / repeat everything you hear.
A dumb sounding thing happened, which wasn’t even a rumor, there were lots of pictures of it - so that means you should believe a lot of other non-credible stuff coming from people who passionately hate Musk?
It is on the listicle of things to make you highly successful.
- Wake up at 4am every day.
- Only hire lucky people (they get to work for you that instantly makes them one of the lucky ones right!?)
- Fire the unlucky people or the people having a bad day (its a pretty bad and/or unlucky day when you get fired, if they had any luck at all you wouldnt have thought of their name when you decided to fire someone)
I don't think they really care who get fired. To those executives in large organizations, individual contributors are no more than a number. As long as they can make the numbers they do care looking better, no one really matters much.
Tastyworks was founded by the founders, CTO, and CFO of Thinkorswim. I worked on thinkorswim institutional desk for several years back in the mid-2000s. Not great brand recognition but a company built for traders by traders.
Very few people use RH as 'investing'. Those will be on boring brokers like Vanguard.
I have a Tastyworks account too - the fills are way better than Robinhood's. As expected, since they charge some amount per trade. But that means that the "free" platform will definitely have more users, just because it's supposedly free (even though you pay for it in the fills, and get frontrunning trades)
>just because it's supposedly free (even though you pay for it in the fills, and get frontrunning trades)
Can you provide a source for this? Citadel (one of the companies robinhood sells order flow to) claims in regulatory filings[1] that the overwhelming majority of orders are executed at market price or better, and that they on average save traders money.
Because they are paying for a supply of (on average) uneducated morons with no edge. Can you imagine how much a professional poker player would pay to be in a tournament with amateurs?
tl;dr: adverse selection. retail traders are less risky to deal with, so market makers can offer better prices to them.
>If the retail trades are random. If retail traders usually buy before the stock goes up, and sell before the stock goes down, the wholesaler would consistently lose money on price risk. (This is called “adverse selection.”) But they don’t. Even now, retail traders tend to be small, dispersed and uninformed. If you sell stock to a retail trader for $58.15, you have no particular reason to think it will go up (or down). The retail traders are trading randomly, which is what allows you to treat this problem as though you were matching them up with each other at a fixed price and collecting a spread. In reality you are matching them up with each other over time, not simultaneously, and the price moves while you are doing it, but the randomness of their trading means that this difference doesn’t matter too much.
>Meanwhile market makers on the public exchange are doing something similar, but with institutional traders who tend to be informed and trade large lots of stock, so their trading does carry a lot more risk of adverse selection. If a big institution buys some stock, that does mean the stock is somewhat more likely to go up, so if you sell them the stock you are somewhat more likely to lose money. This is why the spread on the public exchange—the difference between the $58 best bid to buy the stock and the $58.25 best offer to sell the stock—is so much wider than the 5 cents that the wholesaler charges. The wholesaler is just matching up small pleasant random orders and clipping a spread; the stock-exchange market maker is facing a real risk of being run over by an informed trader.
The numbers are given as examples, not as real figures. If you look at the document from my prior comment the price improvement (and therefore spreads that citadel makes) is on the order of pennies or less.
I don't know the situation now, but both used to sell their order flow to the same place. I used both and fills for pretty much the same. However, I used tasty platform to set up options and then execute them on RH most of the time.
If you are seeing a venue not meeting nbbo you have a whistleblower suit to make which have been quite lucrative.
When I was doing this for work the issues we ran into came down to a) making the orders hit the tape close enough to ensure similar priority b) the size of the orders changing execution depending on venue c) differences in performance per symbol.
This was in a place that was sending a fair amount of orders in. Even then given the above finding statistical relevance was hard.
Well... hactually... This is kind like the opposite of zero-knowledge, where everyone can know your crush just by entering all suspecting names in the link.
Is there a real lock-in in case of 1Password though? I like their UX and integrations, but looks like it is easy to export and move my data to other products if required.
> Sending fraudulent people to jail for a long, long time is fundamental to running a healthy society
Really?! Interesting...
I agree, a functioning society needs good law and order, and some way to prosecute and bring criminals to justice.
But I am personally not convinced that sending someone "to jail for a long, long time" is the solution. How is that productive? I think we need to come up with better ways to serve justice than physically restricting otherwise smart or productive individuals to a room for decades on end. As soon as we are done with abolishing the death penalty, I would want us to start looking at abolishing this "decades long locking up" of folks. I don't have a good solution as I said, but I am convinced that this is not it.
There are many different philosophies of justice. Personally, I find "restorative justice" the most compelling, especially when tempered with the practicality of "preventive justice". But there is also "rehabilitative justice", along with "retributive justice" which is closest to revenge and thus will never lack for popular appeal.
> But I am personally not convinced that sending someone "to jail for a long, long time" is the solution. How is that productive?
At least for murder, one of the strongest predictors of whether a person will kill is if they've killed before. So prison is productive because it makes it more difficult (though not impossible) for a person to keep killing.
Trying to abolishing imperfect parts of society with no tested replacement solution is a dangerous game.
Some people are or became irredeemably antisocial and need to be kept away from society at large. Watch any liveleak video around the mexican cartel if you need a reminder of what evils people are truly capable of.
That being said, sure want to properly reintegrate everyone possible. But society understandably does not exactly welcome past offenders back with welcome arms. It is kind of hard to be productive again when few places will even consider hiring you. That isn't a stigma you can just wish away.
The point of sending them to jail for a long, long time is to protect society from them. Honest people don't deserve to live in a society filled with liars and cheats and conmen. Send them straight to hell
I think the question is whether punitive policies work in that way. I'm fairly comfortable saying this person getting locked up for a long time will probably not deter too many others from doing similar, at a personal level. I suppose it can be argued that it doesn't have to act as a deterrent to individuals at a high rate, but to groups? But... why aren't we then hearing about everyone else that enabled this? (That is, this just encourages more folks to make sure to have a scape goat.)
Or, do we really think it was down to just this one person's actions?
FWIW IMO: This should be marketed to the twitter croud, not the facebook crowd. I have no interest in writing journals for my friends and family, and even if I did, there won't be many who want to read what I write (in my personal network).
But I can see writing for folks with the same interests in tech, business, books or what not. So I am willing to open up my personal journals, but only to complete strangers (anonymously).
IMO while Microsoft and Google should work together to solve this as soon as possible, the longer term solution should not involve Microsoft. This sounds like something Google should fix at their end.
No customization done by the user, including installation of apps should prevent a user from being able to call 911, period.
That's actually a real issue that needs addressing. Any phone that makes 911 calls should still get security updates. All phones that can reach the cell network can still make 911 calls per FCC requirement.
Imagine the worse case scenario where malware infects the phone but requires a credit card to call 911.
Maybe congress will get around to this to make Google and everyone else do the right thing, but from my perspective Google should have done the right thing here.
Worst case scenario? Sounds like best case scenario to me so long as no one is harmed.
It will take some horribly idiotic event like that to get the manufacturers to actually address that when you sell a phone you're selling hardware and software.
If Google are concerned they could fix it more easily that a software update for older, unsupported phones - they could just mark every app that registers itself as a third party dialer as incompatible with older Pixel devices in the Play Store, and remotely remove them from Pixel phones presumably. It'd be a bit "user hostile" but you have to remember that you don't really control the code on your phone if you use Google services, so it's entirely possible for them to act this way.
The thing I think people are missing is that the response from Google indicates that this isn't a Pixel issue. This is a "all android phones on Android 10+" issue.
Without full cooperation from manufacturers, there's really not a lot that can be done outside of blacklisting all dialer apps on the Play store and even that would do little for anything already installed.
I think you miss the point here. Security updates for phones need to be longer than 3 years -- for that reason.
The pixel 2 is already EOL'd 4 years after it's release, but it can still make 911 calls. I believe there are people that still depend upon that phone to make phone calls -- and therefore need 911 when they need it.
Oh definitely. I wasn't disagreeing with that aspect. Everybody had been focusing on how the Pixel line would be able to solve this issue which kinda ignores that bigger issue that the entire industry needs to be maintaining these security updates. There's no good reason for OS security updates to be gated behind manufacturer control.
EOL does mean something. I don't believe 3 years is long enough personally, but even if it was 10 years the same problem would exist, just for older phones. Then it becomes a semantic argument about where phones should ever have an EOL date for critical fixes.
I think Google would argue that malware interfering with your phone after its EOL date is a reason why you should upgrade your phone to a newer model rather than use that as a reason to extend the life of their phone software indefinitely.
What would you like them to do? Google couldn't retroactively make it possible to patch every phone on the planet even if they wanted to, and the phone manufacturers aren't likely to treat this as any more special than the other bugs that they aren't patching
Well, I'd expect them to bring the phones into compliance with the law. Quoting section 22.921:
> Mobile telephones manufactured after February 13, 2000... must incorporate a
special procedure for processing 911 calls. Such procedure must recognize when a 911 call is made and, at such time, must override any programming in the mobile unit that determines the handling of a non-911 call...
If a phone can't access 911, it's not legal. Frankly, it's an indictment of the system architects that this bug is possible at all.
But what if I as the user install software on my phone that isn't capable of calling 911?
I own the phone and I am able to install whatever software and whatever operating system I like. I don't want it to seem like I'm defending Google here, but should manufacturers really be responsible for the software someone installs on their portable computer?
Moreso than most, this regulation is written in blood. The reason this and other FCC 911 rules came about was that there were numerous cases of people trying to call 911 and failing due to software "issues". The FCC said enough and mandated that if it were possible to complete a call, the phone is required to.
Installing your own OS that intentionally doesn't support 911 handling would be in the "not possible" category just like a user who cut their antenna. For anything less than that, Google (and other manufacturers) are absolutely responsible for ensuring the 911 code path can't be disrupted. People have literally died from this.
So you are advocating to put anyone who has a rooted phone that doesn't get this dumb update to fix an issue with Microsoft Teams in jail?
Seriously, this sounds like a Teams issues. Google does by default incorporate what is required and it isn't until Teams takes permission from the phone app that an issue even occurs.
I don't think anyone is expecting google to patch every phone on the planet (assuming you mean every android device ever released). But they should be able to patch every phone of theirs including every old pixel and nexus.
And if they can't, they should make it clear to the user/owner that their phone isn't supported and that means that their lives or the lives of others could be in jeopardy as a result. In fact, perhaps their phones should have an expiration date and should just stop working after sometime. Or at least disable critical functionality that their required to be in compliance with (FCC regulations) since they've decided to no longer support the device. Moreover, this date and timeline should be clear from the point in time when you purchase the device.
Of course this could all be done by the network providers only allowing supported devices on their network, but we all know how that would end up.
This isn't just some bug, and if google wants to participate and be taken seriously in this industry, they should stand by their products and customers.
If they can determine that any phone in usage today running Android software may be prone to this bug they should issue an immediate recall on all devices. That's likely to be almost every Android device purchased in the past couple of years. This scale of recall is not without precedent.
I wouldn’t jump to conclusions before we fully understand what’s happening. Maybe this issue was introduced in the latest version of android (that would be my guess seeing that it was just discovered) thus fixing it in a patch release on that version would fix it for everyone. You with an older pixel have nothing to worry about because you couldn’t update to this version anyhow.
It would also be quite cool is 3rd party apps didn't need and use permissions like "listen to who am I calling". Why a chat/online calling application even need that? Only to collect metadata about their users?
There is a reason this materialized with teams and not with any one of the 10's of thousands of other apps out there: Teams is by far the most invasive piece of shit there is, it tries to hook into everything it can get its grubby little endpoints into.
Both parties are to blame. Teams shouldn't have behaved the way it did, Android should have failsafes to prevent this from happening. A great example of not letting developers do what they want...
Sure, Android should absolutely not allow any apps to interfere with 911 calls, and so however Teams achieves this, should not be possible. But some blame certainly goes to Teams here as well for causing the situation by trying.
One thing I do want to point out is that "not allowing any apps to interfere with 911 calls" is much more complex than it sounds:
1. What about someone who has a tablet (with no cellular functionality) but has a VoIP app installed?
Clearly, the only way to call 911 on such a device would be for it to go through the VoIP app, so it seems like Android at the very least still needs VoIP apps to be able to handle 911 calls under certain circumstances, such as when there is no cellular functionality.
2. How about a situation where a cellular phone has no communication with any cell towers (for any network) but has a VoIP app installed and access to wifi?
Unlikely, to be sure, but possible. In this case, the only way for the phone to reach 911 would, again, be through the VoIP app. If 911 access must get through no matter what, Android would have to let the call go through the app, despite that the phone has cellular functionality.
Those are likely just a couple of instances and there's almost certainly others I haven't thought of.
A solution could be to give the Android system dialer first preference. If it fails to call the number (network issues, no signal) it could automatically pass off the call to the first registered VoIP app
That said, the Google Play store should also have more stringent reviews for apps that want dialer access. Their review should verify whether emergency services can be called regardless of signed-in status, and location
I would be happy to get that somewhere in Google someone is either signing off on such a review requirement right now or has done so in the last couple of days.
I suspect that this little tidbit here is the root cause:
"If a Teams client is not located at a tenant-defined dynamic emergency location, emergency calls from that client are screened by a national call center to determine the location of the caller before transferring the call to the PSAP serving that geographic location."
Also, "If a Teams client for a United States Calling Plan user doesn't dynamically acquire an emergency address within the United States, then the registered emergency address is used to help screen and route the call. However, the call will be screened to determine if an updated address is required before connecting the caller to the appropriate PSAP."
Which is a clear violation of Kari's Law. A business phone system in the US is absolutely not allowed to intercept and divert 911 calls.
Maybe you other reasons to drop Teams, but this would not be one.
Google/Android are clearly tasked with handling 911/emergency calls. Teams is not - I doubt that it is even in their spec - they should expect 911 to route right past them.
Google effed up this one big time.
They need to fix it for every app, not just Teams.
It literally does not matter what Teams does - even if Teams maliciously did every wrong thing they possibly can, it's the duty of the phone manufacturer to ensure that 911 still works, it's Google's duty to ensure that Teams or any other app can't break emergency calls no matter how they try; the law literally requires the phone to recognize that a 911 is being made and override any programming (e.g. Teams) that may interfere with that. If Google can't do that with an over-the-air update, they can issue a full recall for all the affected Pixel phones.
My understanding is that emergency calls for any global locale are supposed to be an entirely separate band of communication from regular phone calls — e.g., they must work even without a SIM card, an account, etc.
So, emergency calls should be ENTIRELY OUT OF SCOPE FOR ANY APP software. Period.
It should be a low-level override/bypass, and NO app software software should ever be allowed to even touch emergency calls, let alone required to handle them.
Expecting all apps to handle life-critical emergency calls correctly is a profoundly stupid idea, guaranteed to produce a multiplicity of failures (and if that expectation did exist, Google must damn well announce it as a deadly serious requirement in bold, uppercase, red flashing letters to anyone wanting to use phone_call_handling permissions, but they don't, afaik).
So, we don't need to know anything about Teams or other app software in this case, only about the emergency calls side/back channel, and that any app, including Teams, will ZERO responsibility for handling emergency calls, or even ability to touch them.
So, it is Google that effed up big time here (regardless of Teams' other issues). Unless you make a solid case for the profoundly stupid idea that all phone-related app software should be responsible for handling life-critical emergency calls, your statement is plainly wrong.
> Mobile telephones manufactured after February 13, 2000... must incorporate a special procedure for processing 911 calls. Such procedure must recognize when a 911 call is made and, at such time, must override any programming in the mobile unit that determines the handling of a non-911 call.
It doesn't matter what Teams does. Android is required to ignore Teams in the case of an emergency call. That's the law.
"More energy = More security" is a slogan now being used to scam non-technical users to buy into the crypto ecosystem, but that does not make any sense if you are willing to think about for a second. Also very convenient that this slogan started getting popular when BTC started getting bad press for energy usage.
BTW how you reach consensus on a chain is different from how the accounts in the chain are secured. Just because all BTC nodes are burning up electricity all the time does not mean that your accounts are more/less secure.
>BTW how you reach consensus on a chain is different from how the accounts in the chain are secured. Just because all BTC nodes are burning up electricity all the time does not mean that your accounts are more/less secure.
I think you're drawing an unnecessary line here. Attacking consensus is attacking the value stored in the accounts. Attacking consensus by using your own miners to pull off a double-spend can directly take value back out of accounts. Attacking consensus by doing a perpetual 51% attack can block people from using their accounts, decreasing the real monetary value of them.
Drawing the lines so that the "security" of a cryptocurrency only refers to the security of the public-key cryptography involved in it is useless. It ignores practically all of the important design considerations and attack vectors in the system. Public-key cryptography is just one component of a cryptocurrency.
I am not a non technical user, and I know how this works.
Btw, you are not correct. The entire history of the chain and balances is protected by the hashrate. With sufficient energy you can rewrite history. This is because every block secures the blocks before it. Yeah checkpoints can be used to force a known sync point, but this vastly undermines the decentralization of the chain.
Google groups feels (UX & support wise) like one of those products that should have already been killed by Google. One of the reasons why Groups has survived so long must be Google's reluctance to give proper customer support for most of their products. Google groups is the only customer support you will get in many cases.
Likely the only reason Groups is still around is that if you want a mailing list on GSuite then this is your only option. If they kill it, many orgs will probably switch to Office 365 or another competitor the next day.
Honestly, this is the only proof I'm willing to accept for the survival of any low-revenue service that Google provides! But still, google code didn't live.
Yeah, Code Search is a counterexample because Google was using it, but killed the public version to focus on internal use. Though it is still available to the public in limited form for Google's major open source projects as https://source.chromium.org/ and https://cs.android.com/
Believe it or not, Groups is the main way to ACL resources in GSuite. It represents mailing lists, user groups, etc. it’s also heavily used in local communities on the consumer side.
I think part of it might be nostalgia as well. If they kill google groups then they are killing yet another part of the old internet they sought to embrace and improve upon but the bean counters have mostly taken over and only a few holdouts in upper management keep this sort of stuff alive.
Also, it was all over the news that Twitter fired probably based on performance (lines of code, yeah, I know). Wondering if this will make it difficult for the twitter folks to get hired compared to those from FB.