We don't know if it hasn't to be honest. State actors and exploit sellers could have known about this bug for years and exploited it before it was found by this white hat
I previously worked for a mortgage software startup that attracted interest from big banks.
To ease concerns about our scalability and longevity, we move from a tiny office to an office with a lot of empty space.
This strategic move supposes signaled to prospective corporate clients that we were committed to sustaining our solution over the long term, rather than just a few years but in the end the company went out of business. so much for that.
Yet the same corporate will eat anything that Google or MSFT does while we all know they kill projects just like anyone else or like any smaller company going out.
I am actually seriously interested in what people there do day to day. I’m wondering this about a lot of very large companies, I would definitely watch a documentary about that.
Hour-long meetings about whether the copy should read "data center," "datacenter," "data-center," or whether it is really even correct to say any of these at all. And then negotiating with the design folks to fit in the extra character. Only to throw it all away because nobody thought about the fact that it has to support 5 different languages.
I wish I was kidding. Used to work at a place that did crap like that, pulling in developers for these time sucks because "only they really know the correct technical usage for our industry."
It's not weird to pick one and keep a consistent style, for example by looking at Google or at Wikipedia or some other source if the dictionary lists both or neither, but to have meetings about it?!
At some point, most of your engineering time is spent on trying to understand what the previous team did. There's probably some engineer at Zendesk banging his head on the table because his boss wouldn't let him fix the sequential ticket IDs when he found them two months ago.
I work in one of the biggest companies of the world (employee and revenue wise) and it's basically a run-off reaction of well-articulated desk employees jerking each other off that, telling each other that they are so very important.
And the common management approach to anything not working immediately is "throw another 1.000 employees into the project" and the middle-managers measure their success by how many employees they are managing so it's a train without breaks. Hope it goes bankrupt soon.
I work at similar size company. Basically they are like most companies building out the next 5 years while also keeping the lights on at four nines. There can be a lot of depth to product that you dont see. Anyone who says "why you need X people" often havn't tried a side hussle where you see 360 all the activities involved.
Building at scale without racking up big bill and hitting SLAs require a decent amount of effort.
Big companies are places where you get kudos for only taking two weeks to solve a problem you’ve solved elsewhere in two days. To an extent it’s Little’s Law. The latency requires more “CPUs” to handle the traffic.
This is super loud to me RN because some of these "big" companies are case studies in Mythical Man Month's "N channels of communication" as well as weird flashbacks to discussions on costs context switching and schedulers in various CS courses.
What's interesting is that Frank Slootman touts this transformation as a huge success in his book and talks at length about his conflict with Fred Luddy (who originally authored the simple ticketing incarnation of the ServiceNow monsterblob). The focus on keeping things simple is highlighted as an example of nerds' nearsighted thinking.
I'm sure it's a huge success for the few earning the profits from ServiceNow.
Like any SaaS, the more feature boxes you check, the more potential customers you can "satisfy". And the worse the UX gets for the average user (which then gets driven to purchasing more support).
Great for business (the few), terrible for users (the many). No contradiction there.
Every single click in ServiceNow takes a full 2 seconds to do anything. For a ticketing system. Insane.
What’s more insane is that it is still better than the vast majority of ticketing software. I don’t know what it is about ticketing and Helpdesk that it ALwAYs ends up like that.
> I don’t know what it is about ticketing and Helpdesk that it ALwAYs ends up like that.
The curse of B2B software is that every new big customer wants some custom feature or configuration that is the "deal breaker" for their multi-million dollar contract signing. And everyone except engineering is eager to give it to them because it's not their problem once the ink is dry. Support and renewals are the next guy's problem.
Software developers being surprised that software companies need to do a lot more than just write code is kind of like sailors being surprised that global logistics involves a lot more than handling a ship.
Never said that, but a competent engineer should be able to build like 75% of the main functionality of Zendesk over a weekend.
Now, I understand there's probably a lot more to it which is why I would expect it to be a company of around 50 engineers and 150 business/marketing/etc and that's being generous.
The hill I'd die on is that, with money not being a scarce resource and a technically feasible challenge present, a team of 200 should be able to build and sustain almost anything in the world. And that's being even generous. I think realistically a team of 50 should be able to build almost anything
Never said that, but a competent engineer should be able to build like 75% of the main functionality of Zendesk over a weekend.
Now, I understand there's probably a lot more to it which is why I would expect it to be a company of around 50 engineers and 150 business/marketing/etc and that's being generous.
The hill I'd die on is that, with money not being a scarce resource and a technically feasible challenge present, a team of 200 should be able to build and sustain almost anything in the world. And that's being even generous. I think realistically a team of 50 should be able to build almost anything
That’s a very HN take but the reality is that the tech is usually never the hard part. Selling, supporting, legal, all the certifications and enterprise contracts you have to do for a product like that are the hard part.
Many people fail to see this. You can't compare a terrorist attack that intentionally targets civilians with no apparent military target to a legitimate attack on a defined military target that unfortunately results in some collateral damage.
Many people fail to see this because they have an intact moral core. Conducting a military operation that has a fully predictable rate of civilian casualties is morally equivalent to targeting those civilians.
Israel has utilized a rate of expected civilian to militant casualties in Gaza at the rate of 100:1 [1].
> Conducting a military operation that has a fully predictable rate of civilian casualties is morally equivalent to targeting those civilians.
By that logic only the absolute number of (expected) civilian deaths matters... which can't be right.
If it were true, then exploding a city bus (1 soldier, 10 civilians) would be more moral than striking a military base (1,000 soldiers, 11 civilians.)
It would also suggest a kind of blame-shifting if one side decides to install their missile launchers in the playgrounds of elementary schools or whatever.
You are simply incorrect. “Rate” is a ratio, not an absolute number.
But to your point, Israel’s ratio in Gaza was as high as 100 civilians to 1 soldier in the shopping mall (or more accurately, refugee family shelters).
No, you've cut off the crucial second half of the sentence, which says a military operation with known risks of civilian deaths "is morally equivalent to targeting those civilians."
The phrase "those civilians" refers to a countable quantity of them.
Perhaps you meant to write "morally equivalent to targeting that proportion of civilians"?
Assuming that's a plural "you", I would paraphrase the subthread like this:
_________
(1) zer0x4d: "Many people fail to see that morality depends on intent, there is a qualitative difference between deliberate and incidental collateral damage."
(2) abalone: "No, only people suffering from broken moral cores think there's a difference. An attack when they knew a predictable rate of collateral damage is morally the same as deliberately targeting those civilians who died."
(3) Terr_: "It's based on the number of civilians who die? That doesn't make sense. Consider these scenarios, where even though fewer civilians die, the intent/planning of the act makes us judge it as morally worse."
(4) abalone: "Incorrect, I said it was about comparing the two rates of death."
(5) Terr_: "Well, that's not quite what you wrote earlier, is this other version closer to what you meant to convey?"
Hi Terr, the "you" was singular (and in reference to you, in particular). You paraphrase the subthread well enough, but your first comment within it misinterpreted what Abalone said.
> > Conducting a military operation that has a fully predictable rate of civilian casualties is morally equivalent to targeting those civilians.
>By that logic only the absolute number of (expected) civilian deaths matters... which can't be right.
Abalone (as well as myself, many others, including the signers of the Geneva Convention) is concerned about the use of force against a civilian population where it is predictable that there will be a high rate of civilian death. Abalone says that is morally equivalent to targeting those civilians and Abalone is correct (it is, in fact, a war crime). It is not necessarily about absolute number of civilian deaths, so your counterexample does not succeed.
I think the argument boils down to "what does it mean to target civilians?"
if 100 die to get 1 soldier, that sounds like targeting civilians. If 1 dies to get 100 soldiers, that sounds like (to me and many others) a successful and targeted attack with minimal collateral damage.
The argument being made sounds like if you know there could be 1 death that you should not target the soldiers and that there is no difference in that case to the 100 civilians to 1 soldier and as such, if any civilian could have been estimated to be collateral damage then no military action should have been made.
I think that is supercilious and discounts reality. Civilians are going to get killed and war is terrible. There is a difference in targeted ratios.
Lavender specifically calls out NCVs as high as 100 for high level commanders not soldiers, and NCVS aren't minimums they are maximums. Where is the actual case where 100 died for one soldier?
There are many points on this grey line, and we often fail to recognise those in the middle. For example, between your two points is a very significant type of action that this one may well fall under: an attack on a military target that you are fully aware will result in significant collateral damage.
This is definitely interesting in the face of the news that Ukraine has been using very small FPV drones successfully on the front lines as opposed to more sophisticated systems like the Bayraktar drones. There seems to be a huge gap in air defense systems when it comes to small UAS and this should effectively address that.
You have to get the costs balanced too- it can't cost 1 million dollars to kill a 250 dollar drone, for obvious "what if the adversary was China" reasons.
I don't understand why nobody has put auto-shotguns on an tripod with an aiming system, like a mini-CIWS.
I've seen Russian soldiers successfully shoot down drones using shotguns, the problem is that the smaller ones can be too fast and nimble for humans to reliably target. Even if you can shoot down 2 of 3, the third one will get you.
Combine the YOLO algorithm with a high-frame-rate camera, a two-axis servo, a heavy tripod, and a shotgun... and you're defended!
This could be mounted on the back of a tank or humvee also.
Something like you describe really does sound like an ideal terminal stage defense system, with 20 or 35mm autocannon covering longer ranges.
Purely theory crafting, I think the final piece would be small, standalone AESA radar units perhaps the size of a man-carryable generator that can be distributed across a given area and networked to likewise distributed shooters, spreading out the targets, adding redundancy to the system, and reducing the odds of your dugout-with-air-defense-asset getting hit by an anti-radiation munition that homed in on a known emitter.
The reason that you don't need radar for this is that the small suicide drones use cameras (vision) to attack. If you can't see them, they can't see you! Contrast this to general aviation where planes can be kilometers up, behind cloud-cover and can attack you with radar-guided missiles.
Radar probably won't have high enough resolution and won't be able to differentiate between drones and birds. Not to mention that most drones are carbon fibre or plastic and won't have much of a radar return to begin with.
Conversely, vision systems could be trained to ID drones reliably, and could use data such as the high-frequency "beat" of the propellers to detect drones from just a few pixels of sensor data.
Shotguns have a very limited effective range. Round pellets have a low ballistic coefficient and lose energy quickly. Using larger bore shotguns only delivers marginal range improvements. Automated shotguns might end up being one aspect of SHORAD, but based on recent developments it looks like they'll end up being less important than jammers plus autocannons (short term) and lasers (longer term).
I think many are trying something along these lines. The devil is in the details.
The shotgun needs to be reloaded. The system needs to be reasonably reliable and durable. Feels like the range of the shotgun is also a problem. The system needs to have some sort of friend vs. foe identification, possibly not shoot at birds or other random objects. The camera needs to be able to deal with looking at the sun and low light, day and night, likely needs to be able to scan. Pretty soon you get to: https://en.wikipedia.org/wiki/Phalanx_CIWS
My point was once you start adapting to all the requirements you inevitably end up with a more complex system. Another thing that happens in a war is that the enemy will adapt to what you're doing.
The principles are fine (well, not sure camera is the right only sensor but aside). The actual engineering of a working system you can use in real life is complicated and that's what many are working on.
A Phalanx_CWIS is overkill. Also, I suspected that the system received continuous upgrades throughout the decades.
Likewise, the Abrams tanks are cold war era tanks, but they are continuously upgraded that a modern Abrams tank isn't really a 1980 tank. Modernization is likely to remove some weight and make Abrams more survivable against drones, in response to the Russo-Ukrainian war;
Ukraine has been using improvised small FPV drones since Russia invaded pretty much. The Russians in contrast seem to have been using larger drones (like those supplied by Iran).
Hezbollah has been attacking Israel from Lebanon for many months now with small drones and the air defence systems like Iron Dome haven't been able to effectively deal with that. One recent example: https://www.timesofisrael.com/hezbollah-swarms-north-with-at...
There is a major effort right now in Israel to address that gap.
> The Russians in contrast seem to have been using larger drones (like those supplied by Iran).
You are confusing short-range and long-range campaigns. Both sides are using fpvs, mavics-style, short-range fixed wing and long-range winged (like shahed-136) drones
I thought the Russians relied more on military gas powered drones (like the https://en.wikipedia.org/wiki/Orlan-10 ) and were not using cheaper fpvs. Certainly in the earlier days there was a lot of footage of Ukranians dropping grenades and mortars via improvised drones and I think the Russians were more spotting with Orlans and then using artillery.
Most if not all the random videos I've seen of cheaper FPV drones were Ukraninian but that could totally be my social media bubble.
That's the case when there is a market where demand is dynamic and a person can simply refuse to buy (decreasing demand) if the prices are too high. Milk is like this.
But in rental market, the demand is not dynamic. You HAVE to get an apartment to live in once your lease is up. If 80% of the complexes around you are on this and on top of that the independents also set their pricing based on the market controlled by the majority, then they can charge you whatever they want. You HAVE to buy and you HAVE to get it with the price dictated by them. There is absolutely no supply and demand in this at play.
You're definitely correct. Not even only on different streaming services. Movies have different cuts too. For instance, Blade Runner has 5 different cuts
Let's be honest here, "good behavior" is extremely easy to demonstrate in prison where everyone else is constantly getting in fights, beating up guards, etc. It's not a high bar and a person like SBF should easily be able to do that.
There is many other ways to get written up and lose time credits like sharing commissary, having too many books, and sometimes fighting is not optional if your cellmates are into stupid things and drag you with them.
It depends if he is sent to a USP like regular federal convicts or club fed minimum because of his connections. Typically club fed you can only get through a plea bargain like Madoff or through years of good time credits.
My experience with ACPI is limited to tinkering with it a bit for installing macOS on unsupported systems, but shouldn't it be possible to avoid any physical modification and do the same with an SSDT that disables the power to the kill switch?
No, the kill switch is a literal electronic connection to the pin on the WiFi card that tells the firmware on that card to disable itself. ACPI may provide an alternative mechanism to trigger the same pin, but that doesn't mean ACPI can be modified to disable the physical switch.
(What may actually be happening is that they switch is telling the embedded controller to toggle the WiFi card pin, in which case modifying the EC firmware might let you achieve the desired outcome, but that's still not an ACPI hack)
When you're talking about Google products, fragmentation comes built-in as expected. There is no reason for 3 versions of maps to exist within Google ecosystem but I don't think they really care
You're conflating the right to do something with whether it is advisable to do something.
Sure, you are ~allowed~ to begin an immediate descent in an emergency, but it is not a good idea considering from the pilot's perspective, the bang is most likely an engine going out and altitude is always your friend in this condition.
In an emergency, caring about ATC is literally your lowest priority, in every case. It is ATC's job to notice a plane no longer under their control and route other aircraft safely around it. Your entire job is to do everything you can to prevent the death of anyone onboard, and playing ham radio is rarely the best way to do that.
reply