>>Professors should teach about AI, include how to prompt efficiently and how to critically scrutinize the output
>100% agree, as with any important technology. But this is just a small curriculum change, just one more topic to cover in the lecture, and maybe a class.
Critically scrutinizing LLM output is just critical thinking skills, something universities should already teach.
Healthcare worker shortages are a problem in the US and other developed countries with universal systems. The type of system doesn't really influence the waiting time.
If the journalist really did make a reservation under the room block for the event, and then was denied attendance to the event, it would seem fairly normal for the reservation to be canceled by the block holder.
Really, if the journalist wanted to cover the event without being noticed he could've done so undercover.
It does not seem likely that he booked it under the Flock room block. The text of the screenshotted email: "called on my behalf and canceled my hotel reservation that I personally made on Hilton's website. They also have not refunded the reservation, as it is now associated with Flock in the system."
It doesn't clearly state that it was part of the room block at Benn's initial booking, and it implies that the booking was not associated with Flock when the initial booking was made.
It depends how it's set up. Often a block will reserve a certain number of rooms for attendees, to ensure people will have somewhere to stay close to the conference site. Usually any unbooked rooms in the block get released closer to the event date.
Perhaps Flock would say that since they were denying the journalist a pass, they should also deny them the room block discount. The hotel could just charge the journalist the difference rather than cancel their room though.
Translator jobs aren't really getting wiped out according to the stats (in the US). Growth is still projected at 2% in the next 10 years.
They also have this to say about AI:
>Computer tools, including artificial intelligence (AI), are making the work of translators and localization specialists more efficient. However, many of these jobs cannot be entirely automated because computers cannot yet produce work comparable to what human translators do in most cases.
>RWE said that it will now reinvest the sum into conventional gas projects, including $900m (£669m) in a liquefied natural gas (LNG) export terminal project in Louisiana.
Yeah, they say that, but I wonder how much of it is just to make the Trump admin happy.
Like, I don't doubt that they will go and build gas projects, and might even use some of this money to kickstart it, but presumably RWE was already pretty far along the pipeline of preparing this offshore buildout, and there's likely a lot equipment orders, staff, ships, etc that they'd rather not cancel, and would rather redirect into another project if they can.
Maybe that's copium from me though, just sad to see a big wind project go to waste.
That's a refutation of agile, Vibe Coding and the last 25 years of the software industry.
One of my own quality metrics that almost everyone rejects is a "a good design is a design where a change that seems like a small change to management is... a small change"
It plays out like this. To get to product-market fit you are going to have to zig and zag 20 times. Everybody optimizes for the first step of this journey and then on the second step they optimize for that... and by step 5 or so the archiecture is exhausted and you have no hope of getting to step 20. The rare team that is looking ahead 20 steps is the one that survives.
>It plays out like this. To get to product-market fit you are going to have to zig and zag 20 times. Everybody optimizes for the first step of this journey and then on the second step they optimize for that... and by step 5 or so the archiecture is exhausted and you have no hope of getting to step 20.
It not being "exhausted" is just what distinguishes a good programmer from a bad one. If you're good you can keep a lid on tech debt in the face of rapidly changing requirements. If you suck at it, well... you can't.
>The rare team that is looking ahead 20 steps is the one that survives.
lol no good software engineering means assuming that you don't have a crystal ball (because you never will) and building accordingly.
This usually means YAGNI, minimizing up front design and refactoring aggressively. These are the things that keep you agile enough to move in many different potential directions in response to different potential futures.
The time when this really got rammed home for me was working on a startup where a political black swan event ended up changing key requirements of our software overnight. This pulled the optimal architecture in a wildly different direction to where we anticipated it was going in the previous week.
> If you're good you can keep a lid on tech debt in the face of rapidly changing requirements. If you suck at it, well... you can't.
Every drop of tech debt (aside from AI slop) I have ever been a part of has manifested simply because some manager or executive made the decision to sacrifice quality for short-term speed. Sometimes this looks like an unskilled developers producing something that management won't let you fix. Sometimes it's a completely unrealistic deadline that requires extreme measures to meet. If you are able to keep a lid on tech debug in the face of rapidly changing requirements, it likely means that you have enough slack in your job to do so.
Asking permission to fix tech debt is a rookie mistake. You need to bake the fixes into the ticket.
Half of my job as a lead is to cajole, threaten and convince juniors into spending 5 days on a ticket to do it properly rather than spending 2 in order to get brownie points for "looking" productive.
Ive had more than one call where the junior says "we don't have time for that" and I have to call in the PM to let them know that it's OK, we do.
There are environments where management put so much pressure on you that you can't help but deliver crap but not everywhere has to be like that.
The problem is that you don't know in advance what the 20 steps will be, and you may spend time solving the wrong problem.
Make step 1 as simple as possible, step 1 is small and changes are cheap, you can even rewrite everything with little effort, no need to prepare for anything at this point.
Step 2-4 will inevitably break something, no big deal, rewrite the parts that need to be rewritten, it is still cheap.
At step 5 rewrites are starting to get costly, but now you have a better idea of what is here to stay, so it is now time to invest in things like regression testing, style guides, etc...
At step 10, you have quite a history, rewrites become a really bad idea, no turning back after that. So now it is time to think about the future. The difference from doing that in step 1 is that you now have 10 steps of experience and only need to look ahead 10 steps.
Then I guess no design is good. Here's an easy example: take any software system you can think of. Let's add a single new requirement: it must produce an output in 1us. I'll bet your system has to change.
Well that's a pretty contrived example. There are fair amount of requirements that can be predicted as "possibly coming" in a given problem space, and a good design typically takes them into consideration and plans contingencies such that a design doesn't crumble.
It's extreme to demonstrate the point, but it's not contrived. Realtime deadlines are a completely normal requirement for the systems I work on. I have change reqs on my desk right now that specify a full reboot back to network responsiveness in <=300ms. That definitely changes how the system is designed.
Contrived does not mean unrealistic. I have seen many extreme requirements come down on short notice. Over time, the peter priciple guarantees that there will be a middle manager that miscommunicates an agenda they dont fully understand, then push an emergency change down the hierarchy.
No, but programmers fetishize speed. Customers usually value it far, far less than many programmers think.
Ive seen many a programmer gagging to rearchitect to speed up an app 2x or 3x when there are 9 other things a customer genuinely wants first and the programmer refuses to believe it.
Most recently it was on a RAG system where an extra 500ms would surely have been appreciated but the right answer mattered 100x more.
You missed the point of the example. The parent said any design that has to change with a single requirement shift is a bad design. So I gave a requirement that virtually any design would have to change to accommodate. It doesn't preclude the existence of other, more plausible requirements that shift designs. I even provided a real example of one, which you've ignored.
Right, the point is that GP's definition should take the nuance you mention into account (namely, that some types of changes are more likely, and thus more important to handle nicely, than others).
I think you are interpreting his claim in the most extreme possible way. You are doing the equivalent of asking a civil engineer what if his bridge needs to support flying cars, or weight half as much while carrying ten times the load. Of course there are architecture breaking requirements, but his point still stands for reasonable and foreseeable changes. If it doesn't survive that, then it wasn't a good design begin with.
Completely untrue. Every design can be destroyed by a single poorly-thought out requirement. I can take down Facebook's design just by saying "any edit must immediately be visible to all users".
That's a straw man argument. Your new requirement is physically impossible. No software team can break the laws of physics.
So the real question is what exactly do you mean by "immediately"? There are many answers with different pros/cons and cost. And I bet the solution won't impact 99% of the software Facebook has already written.
My new requirement is NOT physically impossible. I did not mean "immediately" as in "zero milliseconds", it meant strong read-after-write consistency. It makes facebook so slow and unscalable as to be unusable. Facebook deliberately decided that stale reads are worth it for responsiveness and scale.
So your argument is that no solution could satisfy your new requirement, not even if Facebook rewrote the entire system from scratch.
If that's the case, then your example doesn't really address what we're discussing: whether software can be designed to remain flexible under realistic requirement changes.
A stronger argument would be to give an example of a realistic requirement change that would force all possible software architecture to be rewritten from scratch. Do you have an example like that?
The disk encryption key(s) isn't typically stored in the TPM, it is sealed by the TPM. A sealed key can only be unsealed if the TPM is in the same state as it was sealed against (simplifying some things here). With the proper selection of Platform Configuration Registers (PCRs), this can prevent the key from being unsealed if the system has not securely booted (sealed against PCR 7). In more complicated configurations, it is also possible to seal the key against a particular phase of boot such that it can't be unsealed once userspace is reached.
In your scenario, yes it is bad if the attacker gets root on your computer, but sealing the key with the TPM means they can't retrieve the key itself. Where the TPM helps is preventing the attacker from establishing low level (kernel, bootloader, or firmware) persistence, since modifications of these components would change the TPM PCR measurements and result in a boot failure.
If the attacker is local and they reset the UEFI, the TPM PCRs are now different and as before, the disk encryption keys will not unseal.
It is also generally recommended to use a pin with TPM, which further complicates this scenario for the attacker because the TPM enforces rate limiting. As the other commenter mentioned, the physical access scenario is commonly a stolen laptop situation, where the attacker would not be in communication with the victim and probably wouldn't return the laptop.
Suppose the physical attacker doesn't reset the bios. He boots Ubuntu or any other os which is signed. Will the tpm unlock and give out the key? I guess it depends on the setup and it's possible to unlock only on your own signed kernel but I doubt this is a default?
I think this is like the windows bit locker vulnerability that was seen a while ago.
The windows recovery put the TPM in the same state as the normal windows OS, so it released bit locker keys, but you could bypass the login on the recovery environment.
At which point they will be stopped by Ubuntu login screen which requires user password (or fingerprint, pin, etc).
Basically there are two options for have to enter 1 password:
1. TPM disk encryption + login password.
2. Password for disk encryption and automatic login (doesn't support multiple user accounts well).
no, I mean the attacker boots his own copy of Windows or Ubuntu, which is supposedly trusted by the UEFI keys. Will tpm somehow detect that it shouldn't unlock secrets for this boot?
This is contingent on the sealing policy including PCRs that would change as a result of booting a different operating system, like PCR 11, which, when booting a UKI, contains those measurements. Only sealing against PCR 7 would allow this attack, since the default platform secure boot policy would not need to change.
The keys can be indirectly sealed against specific system and software configurations such that this attack is not possible. Additionally, as you noted, using custom secure boot keys would prevent the attacker from booting an arbitrary OS.
Jokes aside, I agree on the sense that this should be a solved problem. On the other hand, if the only implementation is a broken one, there's only one way to help yourself, and that is learning how to do it and helping yourself
