For more brain explosion, compound that with a "memento mori" timer that converts the time spend in "nothingness" into "how much closer you are to eternal nothingness."
No wonder people watch TV, fight wars, or build startups to forget that.
I would be very surprised if the _trial_ was to take place "very soon". (Trials hardly ever take place "very soon" in France.)
However, I could imagine him staying in custody while being investigated for a couple days, then quickly facing some level of judge to decide whether he has to stay in jail or can be released.
Once this is done, don't expect a formal trial until multiple months (and most realistically, at least a year.)
About the custody thing, he's an extremely high flight risk. If the French authorities are serious about his arrest and it's not just a dumb PR move, there is absolutely no chance he's going to be released. Not without 24/7 police surveillance and giving up on all this passports.
> I could imagine him staying in custody while being investigated for a couple days, then quickly facing some level of judge to decide whether he has to stay in jail or can be released.
I think the original link mentioned exactly that, and it would be done over the weekend
He's a super high flight risk, so I'm thinking the prosecution is going to make a pretty solid case for him staying in pre-trial until trial in a year or two.
He's gonna have a very miserable time. Flying private jet --> watching another man shitting next to you.
Well, he'll only have to see them twice a week now [1]: he's been officially charged, then released (under bail), has to check in regularly, and can't leave the country.
I don't know if that counts as "due process" for everyone ?
Is anyone keeping a track of those "breakthrough" articles in the "breakthrough-y" topics (energy generation / storage, AI, autonomous vehicles, cancer treatment, etc...), with a timeline of "where are 10 / 20 / 30 years later" ?
I don't mean that in a snarky way - it's perfectly normal that not all innovations bear their fruits, that industrialization is harder than expected, etc...
Even if only a fraction of them work, it's called progress.
But I'm curious to know if someone compiles this kind of list.
For example perovskites, which are the focus of this article have gone from having 3% conversion efficiency to 25% efficiency in the last 15 years.
That's amazing progress in the lab but deployment into standard PV markets is effectively zero.
This might change this year, hence articles about deployment, but still only 1GW or so predicted this year.
And even that is "just" tandem cells where you have a layer of standard PV and perovskites working together.
Some of the real sci-fi possibilities of perovskites are of being able to print them easily and cheaply onto flexible lightweight structures entering whole new markets.
But with wider context, it's weird this gets brought up so often in regards to solar PV and batteries which may actually be two of the most impactful technical revolutions in human history, totally reshaping the whole world right now at a breathtaking speed that surprises even enthusiasts that are paying attention.
First patents on solar energy were granted in 1860s. First solar panels were created in 1883. It wasn't so long ago - I still remember - that everybody thought solar energy would stay way too expensive and would never compete with coal or gas, and look what happened.
Solar doesn't compete with coal or gas - it's still not reliable enough to replace base load requirements, and skewed economics around solar have killed new or replacement base load projects. Indeed, the California and Texas screwed up politics and economics are chief contributors to their power instability. My favorite is in CA - mandatory switch to electric cars then ban people from charging them due to electricity shortages. You can't make this stuff up.
Renewables don't do reliable baseload _yet_, that is true. But not being able to completely replace gas does not equate not competing at all. That is a fallacy. For example, we are a laggard on renewables (Netherlands), but are catching up nicely:
If you look at the chart it is clear that as renewables are rising (both wind and solar), fossil based electricity declines (including gas).
This is easily understood when you consider that gas is used to generate way more than the baseload. When solar energy is producing, it is more often than not cheaper than gas, and when it isn't it is easy enough to supplement with gas. That means solar competes, but doesn't replace.
There are lots of problems with the transition we are making, some are real, some are due to stupidity and others to greed and malice. It doesn't help that the solutions have become so politicized. I'm convinced that at the end of the transition we'll have an abundant amount of cheap, renewable and clean energy.
I certainly hope these spray/use/coat-anywhere perovskites are lead-free, and there isn't much info on the other key issue with perovskites: they degrade quickly when exposed to oxygen/air/the atmosphere.
The article kind of sucks, like most gee-whiz solar reporting. Battery reporting IMO has gotten a bit better where they actually address cycles/density/materials.
Multijunction solar is still ridiculously undeveloped industrially, and perovskite or silicon+perovskite multijunction could lead to a lot of progress.
What's important about these articles is that solar, which is already exceptionally cheap in LCOE terms, still has runway to likely drop 50% in price in the next 10 years.
I continue to be frustrated with the cost of home/residential solar, which I think is a key part to avoiding excessive grid restruction, increasing resilience in disaster scenarios, double-utilizing already-industrialized/developed land/structures rather than using "pristine" land, and providing key competition to inherent-monopoly utilities.
So cheaper spray-on or coating-based solar might help close the residential vs grid solar gap.
I'm not a solar cell researcher, just know that perovskites have had the lead content and degradation on exposure to air as their fundamental commercialization blockers, well, and the usual efficiency scaling.
I'm assuming a thing sprayable film which you would most certainly want to be lead-free and inherently would have a higher surface area of air exposure has addressed both, so this would be very promising at 20%+ efficiencies.
It's fairly common for undergrads and graduate students to compile reviews of research technologies to see what is getting commercialized and what isn't.
If you search google scholar or similar for the area you're interested in, and limit it to the last year or two, you can probably find plenty of info.
I made a point of tracking Solid Energy Systems back when they were young and were just announcing their “break through” battery technology.
What’s interesting was that they seemed to go off the radar when they got their investments and initial customers. Hard to find articles and news about them. Recently I found an interview where they talked about that they had been selling batteries to some niche applications with very specific requirements. Now they seem to be coming into the limelight again and have shipped prototype EV battery packs.
In fact it seems like several solid or semi solid state battery techs are just about to reach mass market these days. It’s what.. like 10 years ago we saw all these break through articles (and the obligatory complaints about break through articles)?
Just yday learned something about microwaves (kitchen appliance). First produced by Raythreon in 1947 were big and expensive ($68,000 in 2023 dollars). By 1986, roughly 25% of households in the U.S. owned a microwave oven, up from only about 1% in 1971. Same goes with solar - it's so cheap now everybody can get small installation. So it's breaktroughs, then incremental improvements in efficiency and production cost. Commercial availability allows scaling and further fall in production cost. It takes time...
it's called a "press release". they are often written by the University own public relations or marketing department and sent en masse to newspapers.
simply printing the press release with minor word and paragraph order change ("cooking the press release") is frowned upon but very common.
usually when you see one of those, the very first thing you do is make a note to never go back to that news company, or at least the journalist signing it. but often cooked press releases are not signed.
there are places which compile press releases as a service to journalists having to fill pages.
OP. You know, I made a diligent effort to find a primary source, whether a paper or whatnot. It seems like Oxford is trying to get across the idea there has been a general “breakthrough” or at least recent dramatic improvement, but it doesn’t seem tied to any particular paper. Sometimes it’s hard to tell from paper titles or even abstracts.
On the other hand, it’s Oxford, source of some of the greatest achievements in human history. If they want to trumpet something that’s going on, I’d give them the benefit of the doubt it’s worth a sniff. And here at HN, people who know might chime in.
So, I don’t do this all the time, but I made an exception and floated it, apparently reasonably.
I also had a personal connection, which was the micron thin film aspect, which my dad worked on at a megacorp for his whole career. Would have been great to be able to chat with him about it, ach well.
Beware, the commentator is now going to argue that the covid vaccines were somehow secretly injected before 2020, because, you know, it was part of "The Plan (tm) (patent pending)"
> Beware, the commentator is now going to argue that the covid vaccines were somehow secretly injected before 2020, because, you know, it was part of "The Plan (tm) (patent pending)"
>based on things he/she has not said, trying to make him/her look bad.
They're making themselves look bad, and you're giving the benefit of the doubt to someone who holds a belief that has long been established absolutely does not warrant the assumption of good faith.
Living in France, i'm pretty surprised they manage to find a "cost of living index" being _lower_ now than in 2018.
Sure, things have recessed from the highs of 2022 / 2023, but the idea of a "groceries index" that does not reflect how is has changed to, ahem, shop for groceries is weird.
It's baselined against New York, so you can be more expensive, but not have had the cost of living grow faster than NYC.
This makes it alright for comparing between countries in a single year, but I'm not sure exactly what you get out of comparing the same country within a year.
> (Really, though, it doesn't matter. Your software stack is almost certainly not going to decide the life or death of your business.)
This is the part that's going to sting.
I suspect, given the general admiration for Paul Graham on YC, many people subscribe (if only unconsciously, and at least to some degree) to the idea that using techno X (where X would be Common Lisp in the case of PG, but everyone will insert their own pet tech here) can _by itself_ make your startup successful.
Whereas the sad truth is that choosing the wrong tech can definitely _kill_ your shop, but choosing the "right" one will not ensure its survival...
The key here though is that choosing a bleeding edge tech is more likely to be a problem because it's fairly untested.
I can tell you what ALL the problems with rails are. For the most part they won't even start to bite you until you hit scaling problems. By the time you hit scaling problems with Rails you can probably afford to pay engineers to solve the scaling problems, and/or port off at that point.
I love sveltekit and use it a bunch for my own personal projects, but it's too immature to recommend to others. Instead I mostly point them at Next.js if they want a javascript stack and Rails if they don't. I have created and maintained apps based on both platforms for 6 and 16 years respectively and know exactly what I'm recommending to people.
I was big on Rails scene when it was huge in 2008, and saw a big exodus from it. I found so many of the "Rails" problems were solved by learning two languages: ruby, and sql. People would go to crazy lengths to avoid looking at the queries they'd actually run. I can admit to not really learning ruby as a language by itself, and can now see how much better my old code would've been if I wasn't just blindly shoehorning Railscasts in there.
Similar problems for people who learned angular but not typescript, laravel but not php, etc.
When software engineers start a business, it's easy for them to hyperfixate on technical decisions because those are the types of problems they understand well enough to optimize.
Yep. The problem with the story of bikeshedding is that it assumes people know bike sheds but not nuclear reactors. There are plenty of cases of people who are great at nuclear reactor design but have no idea how workers should park their bicycles.
I've seen a really interesting pattern play out a few times now.
A startup needs to raise money and hitches onto the latest tech stack that grabs investors' attention. The startup raises on a valuation inflated based partly on the tech stack itself, meaning enough attention isn't given to the actual product or business model. Ultimately the startup runs into money problems when they can't live up to the tech stack hype and the valuation that went with it.
I saw this first hand with a startup picking Plaentscale early on. There's nothing wrong with the product and it solves certain problems really well, but I saw one particular startup grab it early because it was getting a lot of attention and completely missed that the limitations of Planet scale ran smack in the face of what the startup wanted to build.
This was when foreign keys still weren't supported by Planetscale. The specific data model was heavily relational and queries were very inefficient without foreign key support. Distributed writes were also important, and if I remember right those weren't supported either though that's a really common limitation.
Assuming a particular tool works for all situations because it works for some is a mistake though. Plenty of companies use all kinds of tools, they're picked to match the specific use case and there is no magic bullet.
> The specific data model was heavily relational and queries were very inefficient without foreign key support.
I can't help but wonder if you're conflating the notion foreign keys (and the usefulness of having them be indexed) and foreign key constraints, which ensure data integrity at the expense of write performance.
I have a narrow view of the performance of MySQL foreign key constraints and would be interested in learning of cases where they might actually improve certain queries.
I'm actually curious what the distinction is in your view. I've never really considered a column to be a foreign key when the constraint isn't used.
Having a column that we give business logic context to is useful, and indexing a column that should contain values for another table is helpful for query speed, but at least in my opinion they really aren't foreign keys unless that constraint lives directly in the database layer itself. I'd say the same for columns that are used as unique identifiers without actually adding unique constraints to the column.
There are good performance reasons to do either one if you're willing to take on the data integrity responsibility in the application code, but the column itself really is just a typed column if the constraints live elsewhere (again in my opinion, I think the technical definitions may ignore this functional argument).
Where I find foreign key constraints helpful for queries is when I need to be absolutely sure of the data integrity. Say I need to make a complex query that joins across three different tables based on foreign keys. If the table constraints exist I know that (a) any value in a foreign key column is valid and the referenced key exists and (b) if no rows are found I can trust that its just because none exist.
Without foreign key constraints, I may not know why the query didn't find any results. It could be because there just aren't any matching rows, it could also be that one of the keys is no longer valid (or never was). If I don't care about that second error state my query may not change much, but if I need to know why the query failed to match and handle any invalid data accordingly I couldn't do it.
When writing, I also much prefer having a single insert that I know will fail if the foreign key isn't valid. This could be done with a more complex query, or a transaction, but then I'd be taking on that responsibility when it could live directly in the db. Beyond the complexity there, I have to assume the database authors would be able to write a more efficient foreign key validation check them I could from my end.
That said, what's been your experience handling foreign keys when the constraint is either unsupported or unused? Do you avoid it mainly for the bump in query performance, and if so how do you avoid that performance hit elsewhere in your code?
Excluding multi-column keys and joins, I'd describe a column as a foreign key in the context of a given query; i.e. when that query references a unique column in a JOIN condition on a related table. This differs from an explicit declaration of a foreign key constraint which provides all the useful referential integrity characteristics that you eluded to. If you said to me "Database Foo doesn't support foreign keys!" I'd take that to mean that you couldn't perform queries with joins.
In my experience, working on systems where foreign key constraints are liberally applied has been a net negative. Certain classes of DML statements (ON DELETE CASCADE I remember as being infamous) are certainly worse in performance than they otherwise might be. As an administrator I remember being repeatedly and painfully hamstrung by the inability to make arbitrary DB writes, which may momentarily violate strict data integrity, but are necessary for immediate practical reasons.
Obviously data integrity suffers without explicit constraints, but I'd rather work to backfill and/or clean up messy data than deal with a frustratingly rigid and poor performing system. I've worked on a number of large-scale MySQL database deployments at various tech companies, and I can't recall many, if any, that required or possessed pristine referential integrity. I can see why it's conceptually compelling, and I appreciate how automated tooling can generate very useful entity relationship diagrams if FK relationships are explicitly spelled out by constraints.
I think the "performance hit elsewhere" only happens given the assumption that strict referential integrity is a requirement, perhaps in a banking context or another where messy data simply cannot be tolerated.
There's no perfect way to do anything in software, especially when it comes to a database.
There are always tradeoffs.
There are times when I'd skip constraints and trust the application logic to handle it, sounds like you've run into those as well.
Personally I just have a really high bar when it comes to moving data integrity out of the db and into the app code. Stale data isn't usually my concern, I'm more concerned with how simply and clearly I can define the data contract with anything consuming the data.
When I can guarantee that a column marked as a foreign key will always be a valid foreign key, consumers aren't at risk of a whole class of errors when reading and writing data. Any one query may be marginally slower because the constraint is in the database and always executed, but I know for sure that I'll never have a frontend blowing up because they didn't realize the foreign key isn't really a foreign key, or a backend accidentally writing bad data because the foreign key value wasn't manually checked for validity before being written.
I can say that the larger the team I've been on the less I've seen issues with data integrity loving outside the database, assuming the project is architected well. When an entire team is dedicated to the database and another team, or teams, are dedicated to just the application logic that manages the db, it tends to be much better documented and tested.
Smaller teams have a tendency to along code around much faster and write fewer tests while still finding product-market fit. In those cases, database constraints are an absolute must in my opinion, app logic is just moving too quickly to have any faith in it maintaining data integrity and teams are often growing quickly enough that stuff falls through the cracks.
Honestly as long as someone on the project is seriously considering the tradeoffs, the team is in a pretty damn good spot regardless of what their needs and preferences end up being though!
Indeed, design is the art of balancing tradeoffs I think. I appreciate your argument for constraints being a guard rail for developers who are moving fast and occasionally breaking things. I think nowadays you can enable and disable the checking of constraints in MySQL dynamically without having to restart the database, which would have greatly reduced my past frustrations.
I’ve worked at 3 large scale startups now that removed all their FK constraints due to performance and inflexibility issues. The lack of them never really caused an issue - I’ve never missed them. If you have a services / multiple db architecture you’re going to have to deal with dangling references anyway.
Pretty sure I found a bunch of fake jobs in my previous research (H2 2023). Best exemple was an SRE job where I'm a 95% match on the (long and specialized) job description, the 5% being some xp in HPC but they have a dedicated team and a separate job offer for HPC specialist, so that sounds fine.
They tell me I "don't have enough experience with debian" and offer me to apply for the HPC job. I go and list them all the experience I have with every bullet point of the job offer, and mention that I've been using debian for 20 years and ask what specific skillset they are looking for. No answer except "all we can do is start the process for the HPC job".
I ended up finding something else where I'm not particularly interested, have no prior experience, but I'm paid way more than my previous job and they seem to love my work despite it being very slow and frustrating. So I'm just going to stick to that, and give up on the idea of finding "the dream job". More recently I found an offer where they told me they have a "multiple month hiring process" and I stopped answering to emails, pretty sure it's fake as well.
I actually saw a job posting that said at the very end "this is just an example". Previously it didn't have that line. So I'm guessing someone complained about being replaced and they had to put that line in there. Unfortunately they have since removed the job posting، It's a YC startup too
> This meant that every user could have their own unique Jonathan setup, pulling together various software platforms, storage devices, and hardware capabilities into their own personalized system. Imagining what would have been required for all this to work together gives me a headache.
Whao. On the contrary, I could imagine plenty of ways in which it would _simplify_ stuff. Imagine if, instead of having a single computer juggling between many software process contending for the same resources, each application was its own mini-computer, with physical separation of memory and processing, and a single, hardware defined way of sharing data ?
At this point, our computers are dumb terminals for computation happening on someone else software, so we're forced to develop distributed systems anyway. But having hardware separation forces doing the only sane thing (the old "share memory by communicating values", as opposed to "communicate commands and share memory")
Sort of, OTP/Erlang on multiple chips of the same desktop box ?
No wonder people watch TV, fight wars, or build startups to forget that.