At the risk of sounding ignorant, why didn't the various police cruisers and even the ambulance itself just push the damn thing out of the way? That's what the push bars attached to the front of their vehicles are for.
When my mom was a firefighter, and a car was blocking a hydrant, she happily broke windows and pushed the hose right through the car. Didn't happen a lot, but did happen more than once.
A human police over eventually got into the drivers seat to move the car. They sat around for minutes before doing so. They could’ve gotten into it immediately.
But yea they absolutely could’ve also just slammed it and moved on too.
The cops only do that if they can be sure they will be able to charge someone else for the damages. For their vehicle, for their "injuries", and also adding in to their department bonuses, but they get none of that if they can't charge somebody with a crime easily. Ambulances aren't really made to do that and are crazy expensive, plus the drivers would likely be taking on a bunch of the liability from the crash, although the ambulance itself likely would survive just fine because they are tough. The fire department are the only ones that have the trifecta of vehicles made to push other vehicles out of the way, are not paid by the extent that they can extort people for money, and are not going to be held liable for damages.
Ambulances can be seriously damaged by attempting to do it. Police cruisers can do it, but then they may be sued for damages. I know that cars blocking fire hydrants were a serious problem in the past and owners sued firemen for pulling water hoses through their cars after breaking the windows - the law was not allowing it even if the line through the car was the only option.
> owners sued firemen for pulling water hoses through their cars after breaking the windows - the law was not allowing it even if the line through the car was the only option.
I'll bet anything you have no citation for this.
Sovereign immunity and necessity combine to make sure that firefighters and cops can do whatever the fuck is required.
The aftermath is even more brutal. You will receive multiple tickets for this, you will receive a bill for damages to the hose they had to thread through your windows (or to the police car that rammed you out of the way), and your car insurance will point to a clause in their policy that says that you are personally on the hook for all of this.
You may even face civil or even criminal liability for any damages to whatever is on fire, or loss of life, that a good prosecutor or plaintiff's lawyer can convince a jury is directly traceable to your egregious conduct in parking your precious car in front of the damn fire hydrant.
The articles I can find say he's staying on as a EP, just stepping down as the main show runner. That seems very different than leaving the show behind.
You can still be a programmer and identify with and participate in that group. AI hasn't eliminated programmers or programming, and it never will.
However, my best advice as someone with many distinct interests is to avoid tying any one of these external things to your identity. Not a Buddhist, but I think that's the correct approach.
He sort of comes to this conclusion in the final "So then, who am I?" section. The answer is you are many things and you are nothing. You can live deeply in many groups and circles without making your identity dependent on them.
If you're a programmer, what happens when programming isn't needed anymore?
If you're a runner, what happens if you get injured?
It's always been helpful personally to remind myself that
I am not a programmer. I am a person who programs.
I align to everything in this post except the below excerpt. I think it's important to be a lot of things and nothing at the same time and to tie fulfilment to internal metrics rather than externalities.
> AI hasn't eliminated programmers or programming, and it never will.
It might not fully eliminate them tomorrow, but this technology is being pitched as at least displacing a lot of them and probably putting downwards pressure on their wages, which is really just as harmful to the profession. AI as it's being pushed is a direct attack on white collar CS jobs. There will always be winners and losers, but this is a field that will change in many ways in the not so distant future because of this technology - and most current CS prospects will probably not be happy with the direction the overall field goes.
Even if you do not personally believe this, you should be concerned all the same because this is the narrative major CEOs are pushing and we know that they can remain crazy longer than we can remain solvent, so to speak.
I don't dispute the shortening of attentions spans, which seems to be directly related to new forms of entertainment young people consume.
However. Films across the generations are very different in terms of how they lay out a narrative. Watch any film before 1980 and you'll start to see a pattern that the pacing and evolution of the narrative is generally very, very slow.
Art is highly contextualized by the period it's created in. I don't really think it's fair to expect people to appreciate art when it's taken completely out of its context.
Lawrence of Arabia, for example. What a brilliant, brilliant film. Beautiful, influential, impressively produced. And really, really boring and slow a lot of the time.
If I were a film professor today, hell even 20 years ago, I would not expect a modern film student to sit through that whole thing. I think it's my job as a professor to understand the context of the period, highlight the influential/important scenes, and get students to focus on those instead of having to watch 4 hours of slowly paced film making and possibly miss the important stuff.
> If I were a film professor today, hell even 20 years ago, I would not expect a modern film student to sit through that whole thing.
Our local cinematheque has just had a 70mm festival, where they of course screened Lawrence of Arabia. All screenings were sold out. My mom went to see another screening at the same time, and commented on how many young people were going to see Lawrence. The past couple of years there has been a strong uptick[1] here of younger people flocking to see older films.
> And really, really boring and slow a lot of the time
If you only watch the story-driven scenes in Lawrence of Arabia, and skip the prolonged shots of the desert, you would miss out feeling the same vastness and heat Lawrence is feeling.
There is a limit to how much a film can make you think or feel. Films that reach the highest limits need "boring" voids in-between the primary scenes. These voids are not to ingest more, but to help digest what has been ingested in previous scenes, with subliminal scenes and silence that let the right thoughts and feelings grow.
> And really, really boring and slow a lot of the time.
It's not boring on a giant display with the original 6-track mix playing just a tad too loud all around you. I've seen it in 70mm at the AFI in Silver Spring, MD; candy for the eyes and ears.
It would likely be boring if played at a quiet volume on a small display. This is because movies are, in part, spectacle. Cirque du Soleil would likely be boring too if viewed very, very far away.
The pacing is irrelevant in this context. As a student the main point of watching these movies is not entertainment.
Although I will say it's pretty amazing that someone that supposedly has an interest in film would not be able to watch The Conversation or an even slower film like 2001.
No you're wrong. It's not about the era. Matt Damon talked about this on the Joe Rogan podcast recently. He was asked by Netflix to create a big action sequence in the first 5 mins so that people on their phones would get hooked into watching the entire movie. He was also asked to mention the plot of the movie several times throughout the movie because people on their phones will tend to miss plot details and it helped keep them engaged.
This is not about how movies are paced, it's about the way phones have changed attention spans.
No he's right, there is definitely a difference in pacing for films throughout the decades.
Much of the content that Netflix produces however is not made to be shown in a cinema like setting - its something that people put on while doing something else, like TV so whatever Damon was saying on a podcast makes sense in the context, its however not indicative of a whole generation of movies - there are still plenty of films being made that require full attention for an extended period of time, many of which are also on Netflix. One could argue that there was never a time in history where more excellent, deep and complex content was being made.
One other part is also that traditional TV (which arguably also never required full attention) has been replaced by new mediums. Personally I never owned a TV in my life.
The whole argument "phone bad" is a bit lazy IMO and doesn't at all take in account the nuance that would be required for a serious discussion.
There is different pacing throughout film history but that's not what the original article is about. The original article is talking about how film students can't sit through movies and that's because of attention spans and phones.
I think part of the problem too is there being so much slop content now that isn't worth paying 100% to which primes people to use their phone while watching for example netflix. And there is no differentiation between "higher quality pay attention to me content" that loses value by not paying attention and "quick and dirty low budget background movie" that loses value by paying attention to everything outside of a few key moments that covers the basic story line.
> If I were a film professor today, hell even 20 years ago, I would not expect a modern film student to sit through that whole thing.
Sorry, but this to me sounds completely insane. We're not even talking about the general population here, but people who are ostensibly serious about the art and craft of film making. And the bar is being set at literally just watching the movie, and not even some obscure marathon of a film that takes a degree to be appreciated, but a major mass-released picture that has already been enjoyed by countless people.
What seems to be missing for me at least is that I doubt I would have done well being assigned entire films on top of my regular course load worth of studies.
Paying attention to a film enough to emotionally connect with the content, take notes, synthesize an academic understanding of subtle things like the use of lighting, sound, camera work, etc while also doing the other several hours worth of homework from my other classes would be pretty daunting.
Much easier to get the clif notes from the Internet and fake it... though I had CS, math and Mandarin courses which were way way heavier on the homework side of things than most other classes I took, so maybe I'm overthinking it.
I like a lot of long films, but at nearly 4 hours, Lawrence of Arabia is a marathon of a film. I've not seen it, I did order a copy recently, but it was cancelled; and I missed the Fathom screening for some reason or another, but I'll see it eventually; I like long movies and movies involving sand, so it seems like an easy win.
I would think a film studies class might not want to spend so much time on a single film, so maybe several scenes would be more appropriate.
I guess that might be a modern interpretation. But I do disagree as well. I actually prefer older films because of the pacing, and fortunately live close enough to the TIFF cinema that I can see such films every other week.
We're not talking about random people pulled off the street and asked to watch Lawrence of Arabia. We're talking about film students. So I don't see how your post is relevant at all. It's like excusing poor literature students because your brother in law struggled with Moby Dick.
In fairness, Lawrence's own book on which the movie is based, Seven Pillars of Wisdom, is a disjointed, rambling, and usually boring book. The high points are really good, but you slog through a lot to get there.
It's an odd position to take, that a crime was not committed or the offense isn't as bad if the difficulties of committing the crime have been removed or reduced.
Yes, it’s still wrong to take things but the guy should get like community service teaching white hat techniques or something. The CEO should be charged with gross negligence, fraud, and any HIPPA/Medical records laws he violated - per capita. Meaning he should face 1M+ counts of …
What does "the crime is less egregious" even mean?
Morally, you burglarized a home.
Legally, at least in CA, the charge and sentencing are equivalent.
If someone also commits a murder while burglarizing you could argue the crime is more severe, but my response would be that they've committed two crimes, and the severity of the burglary in isolation is equivalent.
Now, how do we apply that to today’s current events?
Is it still a crime if the roadblocks to commit the crime are removed? Even applauded by some? What happens when the chief of police is telling you to go out and commit said crimes?
Law and order is dictated by the ruling party. What was a crime yesterday may not be a crime today.
So if all you did was turn a key and now you’re a burglar going to prison, when the CEO of the house spent months setting up the perfect crime scene, shouldn’t the CEO at least get an accomplice charge? Insurance fraud starts the same way…
It's a common attitude with people from low-trust societies. "I'm not a scammer - I'm clever. If you don't want us to scam your system why do you make it so easy?"
The Internet is the ultimate low-trust society. Your virtual doorstep is right next to ~8 billion other peoples' doorsteps. And attributing attacks and enforcing consequences is extremely difficult and rather unusual.
When people from high-trust societies move to a low-trust society, they either adapt to their new environment and take an appropriately defensive posture or they will get robbed, scammed, etc.
Those naïfs from high-trust societies may not be morally at fault, but they must be blamed, because they aren't just putting themselves at risk. They must make at least reasonable efforts to secure the data in their custody.
It's been like this for decades. It's time to let go of our attachment to heaping all the culpability on attackers. Entities holding user data in custody must take the blame when they don't adequately secure that data, because that incentivizes an improved security posture.
And an improved security posture is the only credible path to a future with fewer and smaller data breaches.
We can start by stopping the use of posture like you’re squirming in your seat. I’ve heard that term for the last 10 years and never has it been useful. Policy yes, Practice if you must, Mandate absolutely, Governance required.
Using posture is a kin to modeling or showing off clothes, the likes of which will never see the streets. Let’s all start agreeing that the term is a rug cover for whatever security wants it to be. Without checks and balances.
If your posture is having your rear end exposed and up in public then…
It's a generic, albeit somewhat euphemistic term. I agree we could do with some better messaging. Dirty and direct is usually more effective. How about this framing?
The Internet is a dark street in rural India and your dumbass company is a pretty young white woman walking around naked and alone at 2AM. It's not your fault morally if someone rapes you, but objectively you're an idiot if you do not expect it. Now, you getting raped doesn't just hurt you; it primarily hurts people your company stores data about. Those rapists aren't going away, so we need you to take basic precautions against getting raped and we're gonna hold you accountable for doing dumb shit that predictably leads you to getting raped.
> If your posture is having your rear end exposed and up in public then…
Right, that is most companies' current security posture: Naked butt waving in the air. "Improving your security posture" is just a euphemism for "pull your pants up and put your butt down".
> Using posture is a kin to modeling or showing off clothes, the likes of which will never see the streets. Let’s all start agreeing that the term is a rug cover for whatever security wants it to be. Without checks and balances.
No, I will not agree with that; that's ridiculous. "Improve [y]our security posture" is not some magic talisman used to seize unchecked power within an organization. It's basically just the Obama Doctrine brought to computer security: "Don't do stupid shit".
“Improve [y]our security posture” absolutely is without a definition of posture. Does that mean more monitoring? More security team members?
Posture is no replacement for a plan.
Originally it was “how we follow our plan” but that has since been thrown out the window. Now, posture is code word for cover.
I don’t mean to vent it’s just tiring having to deal with varying degrees of posturing where everyone is just haphazardly laying on a couch watching TV.
This is surprisingly basic knowledge for ending up on the front page.
It’s a good intro, but I’d love to read more about when to know it’s time to replace my synchronous inter service http requests with a queue. What metrics should I consider and what are the trade offs. I’ve learned some answers to this question over time, but these guys are theoretically message queue experts. I’d love to learn about more things to look out for.
There are also different types of queues/exchanges and this is critical depending on the types of consumer or consumers you have. Should I use direct, fan out, etc?
The next interesting question is when should I use a stream instead of a queue, which RabbitMQ also supports.
My advice, having just migrated a set of message queues and streams from AWS(AvtiveMQ) to RabbitMQ is think long and hard before you add one. They become a black box of sorts and are way harder to debug than simple HTTP requests.
Also, as others have pointed out, there are other important use cases for queues which come way before microservice comms. Async processing to free up servers is one. I’m surprised none of these were mentioned.
> This is surprisingly basic knowledge for ending up on the front page.
Nothing wrong with that! Hacker News has a large audience of all skill levels. Well written explainers are always good to share, even for basic concepts.
For me, I've realized I often cannot possibly learn something if I can't compare it to something prior first.
In this case, as another user mentioned, the decoupling use case is a great one. Instead of two processes/API directly talking, having an intermediate "buffer" process/API can save you headache
The concept of connascence, and not coupling is what I find more useful for trade off analysis.
Synchronous connascence means that you only have a single architectural quanta under Neil Ford’s terminology.
As Ford is less religious and more respectful of real world trade offs, I find his writings more useful for real world problems.
I encourage people to check his books out and see if it is useful. It was always hard to mention connascence as it has a reputation of being ivory tower architect jargon, but in a distributed system world it is very pragmatic.
Agree! In fact, I would appreciate more well written articles explaining basic concepts on the front page of Hacker News. It is always good to revisit some basic concepts, but it is even better to relearn them. I am surprised by how often I realize that my definition of a concept is wrong or just superficial.
> when to know it’s time to replace my synchronous inter service http requests with a queue
I've found that once it's inconveniently long for a synchronous client side request, it's less about the performance or metrics and more about reasoning. Some things are queue shaped, or async job shaped. The worker -> main app communication pattern can even remain sync http calls or not (like callback based or something), but if you have something that has high variance in timing or is a background thing then just kick it off to workers.
I'd also say start simple and only go to Kafka or some other high dev-time overhead solution when you start seeing Redis/Rabbit stop being sufficient. Odds are you can make the simple solution work.
I think the article would be a little bit more useful to non-beginners if it included an update on the modern landscape of MQs. Are people still using apache kafka lol?
> but I’d love to read more about when to know it’s time to replace my synchronous inter service http requests with a queue. What metrics should I consider and what are the trade offs. I’ve learned some answers to this question over time, but these guys are theoretically message queue experts. I’d love to learn about more things to look out for.
Not OP but I have some background on this.
An Erlang loss system is like a set of phone lines. Imagine a special call center where you have N operators, each of which takes calls, talks for some time (serving the customer) and hungs up. Unlike many call centers, however, they don’t keep you in line. Therefore, if all operators are busy the system hungs up and you have to explicitly call again. This is somewhat similar to a server with N threads.
Let's assume N=3.
Under common mathematical assumptions (constant arrival rate, time between arrivals modeled by a Poisson distribution, exponential service time) you can define:
1) “traffic intensity” (rho) has the ratio between arrival time and service time (intuitively, how “heavy” arrivals are with respect to “departures”)
2) the blocking probability is given by the Erlang B formula (sorry, not easy to write here) for parameters N (number of threads) and rho (traffic intensity). Basically, if traffic intensity = 1 (arrival rate = service rate), the blocking probability is 6.25%. If service rate is twice the arrival rate, this drops to 1% approximately. If service rate is 1/10 of the arrival rate, the blocking probability is 73.3%.
I will try to write down part 2 when I find some time.
EDIT - Adding part 2
So, let's add a buffer. We said we have three threads, right? Let's say the system can handle up to 6 requests before dropping, 1 processed by each thread plus an additional 3 buffered requests.
Under the same distribution assumptions, this is known as a M/M/3/6 queue.
Some math crunching under the previous service and arrival rate scenarios:
- if service = arrival time, blocking probability drops to 2%. Of course there is now a non-zero wait probability (close to 9%).
- if service = twice the arrival time, blocking probability is 0.006% and there is a 1% wait probability.
- if service = 1/10 of the arrival time, blocking probability is 70%, waiting probability is 29%.
This means that a buffer reduces request drops due to busy resources, but also introduces a waiting probability. Pretty obvious. Another obvious thing is that you need additional memory for that queue length. Assuming queue length = 3, and 1 KB messages, you need 3 KB of additional memory.
A less obvious thing is that you are adding a new component.
Assuming "in series" behavior, i.e. requests cannot be processed when the buffer system is down, this decreases overall availability if the queue is not properly sized. What I mean is that, if the system crashes when more than 4 KB of memory are used by the process, but you allow queue sizes up to 3 (3 KB + 3 KB = 6 KB), availability is not 100%, because in some cases the system accepts more requests than it can actually handle.
An even less obvious thing is that things, in terms of availability, change if you consider server and buffer as having distinct "size" (memory) thresholds. Things get even more complicated if server and buffer are connected by a link which itself doesn't have 100% availability, because you also have to take into account the link unavailability.
I only really ever play one game, so that's not a blocker for me.
I would have switched by now but film and audio production software, including VSTs, don't seem to be greatly supported on Linux. I'd love to hear from someone if you are successfully doing this.
> I only really ever play one game, so that's not a blocker for me.
I play loads of games; its mainly AAA multiplayers that aren't able to run on linux due to kernel anti-cheat - nearly everything else runs well with minimal effort using proton via steam (either installed via steam or imported as a non-steam game).
Music production is indeed still a blocker. I used to use Windows for that; I am now on macOS for work and music (much better than Windows in every way! I use an old trashcan Mac Pro with Monterey for my studio computer) and Debian for my personal machines.
I just launched a 10-Bit Video Thumbnail Provider for Windows.
Windows does not natively support rendering thumbnails for 10-bit videos, which are commonly produced by cameras like the Sony A7IV.
When I started working on a short film the video clips were piling up on my hard drive. Opening them one by one to find what I was looking for was tedious.
I could not find a reputable solution to this problem, so I started a company and built one. I went through the process of EV Certification to have the installer and executable code signed.
I hope to be in the Microsoft Store soon.
I'm also building other utilities with similar purpose.
reply