Seriously? I worked at startups and research institutions. We trained people on interviews. I know Google used to invest quite a bit on interview training.
"Well I would probably go home and work on my resume because that's a fool's errand."
I hate going to work and reinventing wheels all day because the company I work for thinks it's so special that every business function needs a 100% tailored solution to solved problems. I much prefer working somewhere that's able to tailor business processes to conform to existing standards.
I’ve interviewed a few hundred people. Probably approaching a thousand, if not already. An interview is a scenario, and if you aren’t willing to engage in the scenario that we all agreed to partake in, that’s a huge warning sign that you’re going to be difficult later down the line. The point of the question is to have something remotely understandable for both sides to talk about, that’s it.
I'd call it an interviewer failure, not an interviewee failure.
I absolutely want people I hire to be "difficult" when the moment calls for it. If the scenario is one where the right business/user choice is "let them keep using Google Sheets", then the answer I want is "Google Sheets seems fine to me", no matter what people with more power start out wanting. Too many developers have been encouraged to be minions, not professionals.
Ditto for ones who act like everything is a nail for their coding hammer. A developer who can save a company a couple hundred thousand dollars by not turning something simple into a big coding project is a rare and precious commodity. Or should be, at least.
The thing to do isn't to give demerits for "being difficult". The thing to do is to then add something to the scenario where they get into the thing you want them to get to. "For this, we need better access control than Google Sheets allows us." Or, "We need this to be more closely integrated with our accounting system."
Unless, of course, what you're hiring for is the willingness to roll over for unreasonable requests from people with more power. Which, honestly, a lot of places are.
Humans are primates, and primate dominance dynamics are going to be the default absent some conscious choice otherwise. Our whole executive/worker dichotomy is a descendant of the British class system. (E.g., note that airlines specifically have a "business class".) And MBA-driven business culture is focused on short-term managerial interest, not societal value or long-term business success.
I think all of those tendencies come to the fore at any organization that doesn't have either a strong sense of mission or a sufficiently desperate need for success that they pay attention to material reality rather than social reality. With a possible partial exception for things like co-ops and other places where the culture is fundamentally different enough. E.g., Mondragon, or Zingerman's.
I think Google, back in its don't be evil/organize the world's information era, probably qualified. They started with a very strong mission-driven culture rooted in academics and engineering. It took a fair bit of time for MBA dogmas to make it like most other places. But from everything I hear, what once felt almost like a calling now is just another job.
> MBA-driven business culture is focused on short-term managerial interest, not societal value or long-term business success.
This is a common refrain I also believe in and there's an interesting open question that comes up here about whether or not an engineering department should or shouldn't execute an order that intentionally destroys the product for short term gain.
Agreed. To me that's related to the question of minions vs professionals.
If I go to a doctor and say, "Hey, please prescribe me a lot of morphine," the answer will be some version of "hell no". That's because doctors, even if you pay for the visit, have responsibilities to the patient, the profession, and society at large. Responsibilities that should not be overridden by money or power.
The same is true for actual engineers, like the ones that build bridges. But although we often call ourselves engineers, a lot of us don't act like it. We're often more like the minions in a supervillain's volcano lair: whatever the boss says, we do.
We could, as a profession, agree to follow those. We could build an organization that supports people who do the right thing in the face of managerial pressure. We could censure those who don't. I'd love to see it happen, but I'm not going to hold my breath.
>The same is true for actual engineers, like the ones that build bridges. But although we often call ourselves engineers, a lot of us don't act like it.
Because software is the wild west. Maybe there's some exceptions in medical tech, but there's no license at risk nor ethics assossiation to be ousted from (nor to vouch for us) if one day we receive something like: "hey, we need you to triangulate and calculate the parameters needed to bomb this children's hospital. Get to it".
Either we do it and go along with our day. Or we don't and get moved or fired.
In an interview when you’ve been explicitly asked to discuss a topic to have a technical discussion about something is not when the moment calls for it. Doubly so if you’ve been asked twice. If you’re not willing to put aside being technically correct when you’re trying to show off your best self, it’s pretty likely that when things get tough, you’ll behave the same.
> unless of course what you’re being for is the willingness to roll over for unreasonable requests from people with more power
D, do you think that someone saying “can we please talk about a technical topic, here’s an example we’re both likely familiar with” is looking for yes men? I actively want my team and coworkers to challenge me, but I absolutely don’t want to work with that person who appears at every meeting with a list of reasons why we shouldn’t do X.
When I ask an interviewee a technical question, what I want is an answer that is correct technically.
If I want them to give me a different kind of technical answer, then I think it's on me to ask a question that actually requires what I'm looking for. It's not hard! All the Stripe interviewer had to say is, "Ok, great. It sounds like you have a good sense for system capacity. Now let's add another zero to all the load numbers." And then keep increasing orders of magnitude until they learn what they're looking to learn.
I am, just to be clear, not defending people being willfully obtuse or contrary jackasses. But that's not the scenario being described in either the Stripe story or the Google Sheets story I'm responding to. Two apparently reasonable people were asked technical questions and they gave answers that were the right thing for the business.
I think that's good and I like to hire people like that. I get lots of others don't, and I get the POSIWID reasons behind it. But I'm not going to pretend I think it's a healthy way to run an organization. And I also get that the people who like pretense and deference in interviews are not going to like me saying so. ¯\_(ツ)_/¯
I read that as being his emotional reaction, not something he'd say in an interview context. This being an internet forum and all.
What I think he's sincere about is not wanting to work at a place that builds unnecessary stuff. And if people are asking for answers that require building unnecessary stuff, I think it's a reasonable inference that the place is not right for him.
I think interviewing is always a two-way street. If I got the feel that a place was going to have a lot of over-complicated code for me to deal with, or expected a lot of status-driven deference against actual user and business need, I wouldn't just give an interview-ending tart reply. But I would politely finish out the interview and then write them off unless there were other signals that redeemed the bad interview questions.
>do you think that someone saying “can we please talk about a technical topic, here’s an example we’re both likely familiar with” is looking for yes men?
Probably. You say "likely familiar with" but interviews are conducted as if it's a pop quiz. Which I never understood.
If you want to have a decently technical discussion, why not just tell me ahead of time what topic and I come to the interview with research? Why do I have to guess that we're talking about dyanmic programming and be punished if you really cared about graph traversal? (meanwhile the interview is for an embedded programmer. Definitely reflects what you'll really do on the job).
I really hate how few initerviews really felt like they were testing my knowledge related to proper fundamentals and not treated as some pseudo-SAT schlock.
> You say "likely familiar with" but interviews are conducted as if it's a pop quiz. Which I never understood.
Sure - the point of being familiar with it is so that we don't have to spend a chunk of the very limited time we have explaining a problem space, and we can talk about the technical stuff.
> If you want to have a decently technical discussion, why not just tell me ahead of time what topic and I come to the interview with research?
I try really hard to design interviews to not require take home work. I don't have stats to say whether this is right or not, but my goal as a HM is to try and keep the process to recruiter/HM call, 1/2 tech interviews and an interview with someone else on the team who is not a programmer (I hire in games so you're pretty much guaranteed to be working with Artists/Designers).
but also maybe its a green flag in that this employee might see the wood for the trees and save the company a lot of money later down the line. In my experience, a lot of engineers can waste a lot of time dicking around re-inventing wheels and whatnot.
While you consider it a huge warning sign, have you ever employed someone who would answer that way or are you assuming that you're not capable of making hiring mistakes? I can't help but think this "huge warning sign" might simply be a cognative bias where the interviewer is misdirecting their frustration in the poor design of their own process at the candidate [0].
For reference, I think both answers are fine and both perspectives (its a positive or a negative) are equally valid. Its just that I don't think we can confidently state either way.
> While you consider it a huge warning sign, have you ever employed someone who would answer that way or are you assuming that you're not capable of making hiring mistakes? I can't help but think this "huge warning sign" might simply be a cognative bias where the interviewer is misdirecting their frustration in the poor design of their own process at the candidate
Yes, I did. More than once. I always regretted it. Sure it could be a cognitive bias, but the entire interview process is essentially trying to figure out “can I work with this person”.
> I think both answers are fine and both perspectives are equally valid
I disagree - refusing to engage with the interview because you don’t like the question is perfectly valid to do, but don’t expect me to want to work with you over it. We’ve only got an hour, maximum, so any scenario we come up with is going to be contrived and simplified - if you can’t accept that then I’m going to make my decision based on that.
> Yes, I did. More than once. I always regretted it.
Fair.
> I disagree - refusing to engage with the interview because you don’t like the question is perfectly valid to do, but don’t expect me to want to work with you over it. We’ve only got an hour, maximum, so any scenario we come up with is going to be contrived and simplified - if you can’t accept that then I’m going to make my decision based on that.
Sure but lets not forget the other perspective. Candidates have to interview for a cumulative many hours over the course of a job hunt, only to have many interviewers batter them with an array of 1337code, pop quizes or contrived examples, none of which reflect the day to day work of the position they will fill. From their perspective their answer could well be a good one, albeit I agree that having some level of willingness to engage in the theatre is a positive sign.
In an auto-interview I recently did, I was given extremely limited time to "refactor" a bunch of code that was clearly broken. I chose not to refactor and instead fix the brokeness of the code, however I entirely expect to fail the interview because I fixed the problems instead of removing a couple of obviously duplicated code blocks. I can see why I would fail by not "following orders" but their async code was broken and the awful exception handling botched all their telemetry. From a "big picture" perspective I did do the right thing but it might be the case they're too stupid to know that I was doing the right thing (they're a multi-language company, so I assume they're less good at the language I specialise in).
Personally I think due to lack of industry organisation around certification or any sort of guild or union, we have a seriously difficult problem around hiring across the industry. In response to the extremely challenging task of vetting programmers I feel like orgs are simply fishing for reasons to disqualify candidates, as a reaction to this problem.
The rare positive experiences I've had interviewing were Amazon, who act like they want you to succeeed instead of fail or orgs that just half-ass it with low bar challenges, who seemingly accept that they're not capable of perfectly vetting a candidate.
and if you hire only based on solely on employee compliance then you are also probably missing the wood for the trees. I've worked in such orgs and they're extremely vulnerable to cargo culting.
I’m not hiring on compliance. I’ve accepted that his answer is correct but asked for the purposes of the exercise if he can put that to a side so we can talk about it. I’ve worked with and hired people like this and they tend to turn every molehill into a mountain, which is just killer on a small team.
I think you missed the point in GP's post. Not all organizations optimize for problem solving. Some organizations prefer subordinates who follow orders (or better, is able to read the mind of the boss to decipher what order he is actually making) than those who breaks out of the box and says ”just use gsuite, boss."
sure but if its not a privately held business then using gsuite is better for the shareholders. Ultimately its the bosses choice, but for the board to fire them its worth knowing they were aware of being able to use gsuite instead of pissing away resource on a needless project.
and if you don't understand my position then you've failed to interview. Some people just seek reasons to disqualify candidates and I think that's a pretty basic approach to interviewing. Remember, we all have a cognitive bias to hire ourselves and part of improving interviewing process is about trying to mitigate that by creating an environment where the interviewee can show the best of themselves, which may not necessarily reflect our own strengths. This is why pop quiz questions are kinda crap and while 1337code is better, its still kinda crap
> What would you do if two different people were emailing a spreadsheet back and forth to track something?
> I’d use google sheets
> Excellent answer, that is what I would do as well, now what if we wanted to build it in-house?"
> Well I would probably go home and work on my resume because that's a fool's errand.
I’ve not failed to interview. The candidate has been a jerk. Could I have asked a better question? Sure. Could the candidate not have sneered at it and thrown a strop - definitely.
Most real-world scenarios aren't so arbitrary, and hardly any have a "right answer". If I had a candidate that broke out of the box of our interview to give a good answer, and that's not the answer I "want", I'd be more likely to believe the interview question is the problem, not the candidate.
remember that we already did the "Excellent answer, that is what I would do as well, now what if we wanted to build it in-house?" part.
the "good answer" was already acknowledged, the "real-world scenario" answer was accepted.
the second part ("what if we wanted to build it in-house") is purely hypothetical to gauge how the interviewee would approach the specific technical challenge (shedding some of the "real-world" constraints so that the focus is technical).
if they again say "well that is dumb i would just use sheets", that is absolutely an interviewee problem.
Depends on the dyanmic. If you have an excellent candidate you're trying to poach, it becomes an intervewing problem because you're wasting both you and their time.
If they are a dime a dozen, then it becomes their problem. Whether or not they care it's their problem depends on their circumstance.
I'm not OP but - an interview typically has a power imbalance. They have a job and you want the job, therefore the balance tips in their favor. If the candidate is a headhunted candidate (imagine a video game studio trying to hire a creative director from another studio) rather than a cold application, then the power is flipped and the company is trying to convince the candidate to join them.
I also feel it's very easy for a good interviewer to bring the conversation back to the desired scenario.
Anything from "imagine we are in a parallel universe where Google Sheets has not been invented yet" to "how would you design a google sheets competitor" would do the trick.
Yeah - for sure. When I’m interviewing I want to give the candidate the best chance of success and to show off both what they know and how they will work with me.
I generally give it three goes with questions like these - the initial ask, and two clarifications. If we’re not getting anywhere I move on.
Depends on the dynamics here. Remember that an interview is 2-way.
Someone giving an answer like "that's a silly, unrealistic scenario" is more likely than not someone who isn't in need for that job to begin with. I'm sure it's something many wish they could say, because the interview pipeline can be very grating. But not everyone needs to play that game.
> The point of the question is to have something remotely understandable for both sides to talk about, that’s it.
I think a lot of people miss this point.
Real projects are complex and have tons of context at the historic layer, political layer, and technical layer. If I have one hour to do the interview, I need to get to some shared context with the candidate quickly, or else it'll just be an hour of me whining about my job. And I usually don't need someone who is already a senior subject matter expert, so I'm not going to ask the type of question that is so far down the rabbit hole that we're in "wheels haven't been invented yet" territory.
Fundamentally, that's why I'm asking a somewhat generic design question. I do also dig into how they navigated those layers in their past experience, but if I don't see them in action in some way then that's just missing signal I can't hire on, and that helps neither me nor the candidate.
In another company or timeline perhaps I could run a different interview style, but often you're working within the constraints of both what the candidate is willing to do and what the company standardized on (which is my current situation).
I think the contrived scenarios you come up with need to not have a trivial solution. Everything about my brain is optimized for KISS, it breaks everything to turn down simple solutions to reach for something more complex.
Think of it this way: they're paying you lots of money to build something boring that has a lot of prior art/research available to you for free. This could be the easiest money maker in your life.
It's not your problem they're hellbent on building a new wheel. They're willing to pay you!
Chances are, you've thought of your own pain points in whatever they've asked you to build and you've now got an opportunity to shine by solving them and demonstrate your expertise.
There is a tool invented lately, that's very good for solving problems, that are well-researched and had been solved multiple times already.
This tool is actually why there is a RAM shortage in the world right now.
Some even say, this tool will replace a lot of workers soon(sic!).
"That does sound like something nice to have. However, recreating Google Sheets is a substantial undertaking. First, we need to evaluate the business case for duplicating something that already exists to ensure that there is a net benefit in doing so. Second, we need to determine if the business has sufficient capital to see the project through."
I suspect a lot of businesses are going to make this mistake in the "SaaS is dead" era as companies try to eliminate $50k/mo subscriptions for boring business software, and they figure it's easier to burn AI tokens creating an internal solution they didn't plan on maintaining in the far future.
> Tesla has 4 different, 4 person cars. It's redundant.
You are spot on, it makes sense to have the Model 3 (economy sedan) and Model y (upmarket crossover SUV).
My question here is why did Tesla have four 4-person cars in the first place? If you wanted to streamline engineering and supply-chain why have Cybercabs instead of using the model 3 or model y as the base? Why split the company between Optimus and making cars?
Cybertrunk does make sense, it is a technology demonstrator and test article filled with all the new ideas and tech they are going to build into the next generation. They get data on people using it by selling it to them.
What you say is a sound strategy for Telsa to peruse, but they don't seem to be perusing it.
EVs are a solved problem, but as amelius notes the real tech is the battery. Tesla + Panasonic has a built in advantage in terms of battery manufacturing. Tesla has a massive amount of capital, if they put it into reducing and scaling manufacturing of vehicles and batteries, I think they could probably win. Now maybe Telsa has looked at the numbers and decided they can't win and are choosing to pivot rather than die a slow death.
I don't think that is what is happening here. Instead, Tesla is continuing the strategy that brought them to this disaster of going all in on driverless. That isn't a bad strategy, but if they get the timing wrong a third time, they destroy the company and they have gotten the timing wrong on this twice already. This strategy has two downsides:
1. AI has no real moat and Tesla has largely pursued commodity sensors, meaning that other than EVs+battery tech (which Tesla appears abandoning), robotaxis have no hardware or software moat.
2. They could use network effects to win, in which case their competitors are not other car companies but Uber and Lyft. Uber has been pursuing the same long term strategy at Tesla.
Now by itself, going all in robotaxi, is risky but could work if they time it right. Tesla isn't going all in on robotaxi since they are splitting the effort between robotaxi and Optimus robots.
It is likely that the experience Tesla gets with Optimus robots will help other robotics companies, but unlike robotaxis where the timing might (but probably won't work), the timing is clearly isn't right for Optimus.
It seems like the motivation here is that Musk is aligning Tesla to a narrative that justify the absurd stock price, even if that narrative isn't reality.
> It seems like the motivation here is that Musk is aligning Tesla to a narrative that justify the absurd stock price, even if that narrative isn't reality.
Since Tesla stock has always been 90% based on the narrative, the narrative is the reality (and the product) of Tesla, and the actual machinery made and sold are just props and decorations to create the impression of it.
Maybe they should rebrand themselves as poTemkin: keep the T logo and the mysterious Slavic vibe, while shedding the pretense about what they're about.
Won't affect the stock anyway. Everyone knows the company is overvalued based on promises and perception alone.
Everyone's just betting on the charade going on one moment longer than their hold on the stock.
If you squint, the Cybertruck is shaped like a pyramid on wheels, which couldn't work any better as a visual metaphor for the enterprise.
If Tesla has lost the advantage in battery tech, that is unfortunate and speaks poorly to Tesla's long term strategy. Reclaiming this lead would be an important strategic goal and I disagree with that not being prioritized.
> Why? Other robotics companies have been doing it for longer. Is Optimus better than Atlas:
Atlas costs about half a million dollars, targeting a price tag of $160,000 once mass produced, and assumes the user will be able to do some maintenance.
Optimus is targeting a price tag of $30,000, but probably costs around $80,000 to produce. It is plastic, it is cheap, it doesn't work.
Atlas is better than Optimus but all measures. The advantage of Optimus so far has been, the mass production-->usage until failure-->improvement cycles that are already underway. Tesla is, as an extremely high cost, slipping on every single banana peel first and this is clearing a path for other companies to learn what doesn't work when you switch from functional over-engineered robot to barely functional robots that can be mass produced.
Telsa isn't alone in this space, but they investing a lot and trying to cut corners. So much of engineering is learning the corners you can cut and the corners that cause a battery fire after 8 weeks of use.
> Tesla + Panasonic has a built in advantage in terms of battery manufacturing. Tesla has a massive amount of capital, if they put it into reducing and scaling manufacturing of vehicles and batteries, I think they could probably win.
This is a very wrong way to tell the story.
Tesla + Panasonic were the first to commit to a massive factor car cells with very advanced chemistry. But this advantage didn't hold long as the model was soon copied.
And at that point, when that investment happened Tesla did actually not have 'a massive amount of capital'. And Panasonic also didn't, and even more so, Panasonic didn't want to go all in on batteries. As they were a company from Japan that still believed in the Hydrogen future.
By the time Tesla had serious capital, the other battery companies had long shot past Tesla+Panasonic and it wasn't even close.
Claiming that Panasonic and Tesla can win now is just silly and based on nothing.
Tesla was actually pretty clever on this and invested rather a large amount in their own battery supply chain. And they spun up a whole battery supply chain pretty quickly. But arguably they were a bit two ambitious. Musk really pushed the boundary with the cells, introducing or trying to introduce a lot of things that were hard to do and simply took time. They should have started more conservatively first and only tried to innovated once they could match the other companies on the standard process.
There was no chance for them to be a massive battery supplier to the outside, but making their own batteries for their own cars and getting better margin then all the other companies was well within the cards. And that by itself is a win.
But overall their battery strategy wasn't really the problem. They did a lot of good things there. And things that can pay off over time. The problem was to much investment in stuff other then batteries and their car models. The most important thing for them was to have growing volume every year. Work on manufacturing improvements and fight on margins.
But as you say, I agree the focus on driverless was a mistake.
Yes, but it is more difficult than jamming a typical radio antenna because the starlink uses a directed beam rather than a omnidirectional radio broadcast. This either requires enormous amounts of power, targeting the satellite itself with a directed radio beam, or getting between the satellite and the ground station by bouncing a signal off the ionosphere.
The above is for jamming directed beams in general. It is likely that starlink has a number of other jamming countermeasures.
Bouncing signals off of the ionosphere is most definitely not an option here. The bandwidth of the signals that Starlink needs in order to provide service are far wider than the range of frequencies that bounce off any layer of the ionosphere. If you could get a 10GHz signal to bounce off of the F layer, you'd have a lot of very excited amateur radio operators who would start using that instead of the moon as their reflector.
Beamforming is essentially yet another way to achieve gain, just like one does with a directional antenna. The Starlink terminal achieves a gain of roughly 33 dB, which means it talks (and also listens) in the peak direction at power levels that are around 2000x higher than what one would achieve with isotropic antennas. 2000x sounds like a lot, but it is actually not impossible to reach. Consumer electronics sends at most a few Watts of RF power, but serious jammers of the type used by militaries can run kilowatts. If you consider the peak power used for brief moments of time then you can get as high as megawatts - the famous AWACS aircraft briefly flash half a continent at somewhere around 1 MW, with average TX power of ~single digit kilowatt.
This assumes you're jamming very close to the dish. The trouble with jamming is you have to deal with the inverse square law so you really can't deny very much area. If they have a fleet of hundreds of high power modern directional jammers they could degrade this or other networks, but they're just not going to have that kind of sophistication.
Huge idiot here with an honest question: with starlink, could a rogue actor just point a bunch of high-powered lasers at the satellites and brick them?
In short, likely no(unless the satellites are really sensitive). Otherwise lasers would have negated the fear of ICBMs long ago.
Because the atmosphere absorbs a lot of energy of the laser beam and focusing the laser beam to such a distant target is not easy. So you cannot just use some high powered lasers, as it would be just a bright spot at most. It would be different, if the laser would be space based, but that is out of reach of Iran's capabilities. They might have anti satellite rockets, but using them against US property in space would create other problems for them.
There are 9400 active Starlink satellites & they can be launched 28 at a time on a partially reusable rocket. The orbit they operate on is largely self cleaning due to being quite low. The satellites operate in many planes and bands + form a mesh network with laster interconnects.
Sure, if you want to try that and bankrupt Iran even more via its militarry rocket program, you can do that and maybe destray a handfull satellites, provided you can actually hit them and the rocket/s does not fail. And you might even get a nice casus belli as a free extra.
I'm not a rocket scientist, but I guess even a single lunch in the retrograde direction should be enough. You lunch a box of ball bearings with a plastic explosive to spread them out, and then just wait. The cloud will pass over Iran every 12h or and will stay in orbit for quite a few weeks, since the orbit is even higher than ISS reboosting once a month, and balls are highly aerodynamic compared to the Starlink flat sails. The cloud won't be very big, but it will repeatedly swipe through quite a lot intersecting prograde orbits. I guess the chance would be quite high. Iran can also split payload into smaller boxes and "deploy" then in sequence while the second stage is firing, then detonate them, to spread out even more.
I haven't seen an AI successfully write a full feature to an existing codebase without substantial help, I don't think we are there yet.
> The only question is how long it takes to get there.
This is the question and I would temper expectations with the fact that we are likely to hit diminishing returns from real gains in intelligence as task difficulty increases. Real world tasks probably fit into a complexity hierarchy similar to computational complexity. One of the reasons that the AI predictions made in the 1950s for the 1960s did not come to be was because we assumed problem difficulty scaled linearly. Double the computing speed, get twice as good at chess or get twice as good at planning an economy. P, NP separation planed these predictions. It is likely that current predictions will run into similar separations.
It is probably the case that if you made a human 10x as smart they would only be 1.25x more productive at software engineering. The reason we have 10x engineers is less about raw intelligence, they are not 10x more intelligent, rather they have more knowledge and wisdom.
Even if you are going green field, you need to build it the way it is likely to be used based a having a deep familiarity with what that customer's problems are and how their current workflow is done. As much as we imagine everything is on the internet, a bunch of this stuff is not documented anywhere. An LLM could ask the customer requirement questions but that familiarity is often needed to know the right questions to ask. It is hard to bootstrap.
Even if it could build the perfect greenfield app, as it updates the app it is needs to consider backwards compatibility and breaking changes. LLMs seem very far as growing apps. I think this is because LLMs are trained on the final outcome of the engineering process, but not on the incremental sub-commit work of first getting a faked out outline of the code running and then slowly building up that code until you have something that works.
This isn't to say that LLMs or other AI approaches couldn't replace software engineering some day, but they clear aren't good enough yet and the training sets they have currently have access to are unlikely to provide the needed examples.
With Trump it appears a window is closing on the development of important technologies and research. I doubt we will enter a new dark age, but in some areas, progress is likely to slow, which in turn will be used as evidence that it isn't worth funding, which will cause funding cuts and result in even slower progress. Everyone is racing to get stuff done, because there might not be the money tomorrow. It seems likely to me that longer term, more ambitious projects are probably being sidelined because there isn't time to complete them before the pencil pushers in the whitehouse defund them.
Look at how the Nixon administration and congress gutted NASA. It took nearly 40 years to crawl out of the hole in the roadmaps that their shortsighted stupidity created. We could have had reusable rockets, aerospike engines and Nuclear Thermal Propulsion in the early 1980s. Instead we got halfway measures like the space shuttle and the ISS that both ate budget but didn't create the required innovation for lower cost to orbit.
Science works better with collaboration. If China and Europe have to take up the slack from a self-inflicted wound to US research, science as a whole suffers. There is far more science to do than scientists and when science funding gets canceled the number of scientist decrease.
After the US canceled the SSC, Europe built the LHC. The LHC isn't a one for one replacement of the SSC, but it would probably not have been built if the SSC had been built. What scientific projects would Europe have built instead? What did we lose?
But only to the extent that the regime fails to get its way.
If the regime continues, they will definitely push us back to a dark age, partially intentionally, partially through not caring about the future or being too stupid to figure out the consequences. And Theil, Musk, Vance and that whole lot are part of the crew pushing for that — technology for me but not for thee.
LD_PRELOAD is so useful for non-malicious stuff that I hope it doesn't get a reputation as a bad thing to find on your system. That being said, I agree with you and also disagree.
From a defenders perspective, you have lost if an attacker has root access on your system. You are right. Consider instead the attackers perspective.
To an attacker compromising and system and gaining root is just the first step of a many step process. One of the hardest steps is modifying the system to silently collect and exfil secrets and data that is valuable to you. Let's say you want encryption keys and only keys, how do you get them? For the sake of example say they are stored on the file system and you want to exfil them as they rotated weekly. Do you write a program with a cron job that checks once per day and uploads them? What if three months later they switch from rotating their keys once a week to once every two hours?
1. How long does it take you to notice your missing most of the keys and what is the cost of this failure?
2. Once you notice you aren't getting all the keys, you need to figure out why. This can take time and money. Do you access the compromised machines again? What if you can't get back into the machine again to figure what happened?
3. Once you figure out why, you need to deploy a patch to your exfil kit. This again costs time and money. What if you didn't test it properly and it breaks the compromised host and exposes your entire operation? You might have to push this one to thousands of compromised machines.
Instead, use LD_PRELOAD to hook filesystem writes, pattern match the key format on and exfil the keys as they are written. Since the hook is environment variable based, it can survive changes to the targeted program. Granted there are other approaches as well, but LD_PRELOAD is simple, powerful, flexible and often used for non-malicious things so it doesn't immediately trigger alarm bells.
reply