Is there a reputable source for these claims? Given source has been proven to lie about scale, delivery, and functionality, especially for topics that might boost share prices. https://elonmusk.today/
“The utility company said that by August, xAI would have access to around 50 megawatts of power, or only enough for around 50,000 chips, and that an upcoming electric substation on the site would give him another 150 megawatts—enough to power 100,000 chips or more. But that wouldn’t happen until 2025, the utility company said” [1].
https://github.com/tktech/chancy is a very early-stage pet project to work around specific issues I keep running into with Celery that has all of this, including a simple plugin-extendable UI with DAG workflow visualization.
While you're right, in the specific case of navigation apps (Google maps) or apps that need navigation data (uber), it's typically because of the Geospatial Information Management Act. High-quality mapping data isn't allowed to leave the physical borders of Korea so most foreign companies just stop trying. Nowadays it's just protectionism, but the original justification was to make it harder for north korea to aim artillery.
Yes, there won't be as many customers purchasing 150-200 tons of lift, but that's the point of "rideshares". All that really matters with space launches is the cost per kg and if it's capable of lifting multiple payloads into multiple orbits, it'll have 10-15 customers per lift, not one. The current model has a kind of pez-dispenser but for chucking out multiple payloads.
There are purchasers for the full lift capacity too, like ISS modules and major telescopes.
If you think about this, it doesn't make a lot of sense because different satellites are going to sit in very different orbits.
Geosynchronous satellites are an obvious case where satellites will collect into a limited number of orbits but they vary on what point of the Earth they sit over. Also getting to geostationary orbit takes a lot more fuel so the rocket has less room for payload than, say, low EArth orbit. I'm not sure one rocket can launch a geostationary satellite above the Americas and above Europe in the same mission.
But you can't really launch a satellite in a polar orbit and an equatorial orbit in the same mission, for example. Likewise, how economic is it to deploy one at 150km and another at 250km?
Starlink is a special case because it's a related constellation of satellites where a number of satellites are in the same orbit.
The (unproven) target cost per kg of a re-usable starship, from even the most conservative source I could find, was under $300/kg[2]. The next cheapest, the Falcon Heavy, is around $2.3k/kg[1]. The cost difference is astronomical, and so low that it becomes viable send less payload and more orbital adjustment fuel, not to mention its (again, unproven) designed to be refueled in orbit. At that price, you could fly multiple refueling flights and still be under the cost of any other life provider.
> I'm not sure one rocket can launch a geostationary satellite above the Americas and above Europe in the same mission.
It can. Geostationary satellites are a certain distance above the equator. If they adjust their orbit a tiny bit lower than that they start to drift east, if they adjust their orbit a tiny bit higher they start to drift west. This process is called "repositioning".
Generally there is a tradeoff between how much fuel you spend on it and how fast the repositioning is done. So you can do it quick and then your sat will have less fuel for position keeping. Or you do it "slow" and then you preserved more fuel potentially extending the lifetime of your satellite.
But these are all done with tiny bits of fuel (compared to the fuel needed to put the satellite up there in the first place) because the delta-v involved is very small.
> I'm not sure one rocket can launch a geostationary satellite above the Americas and above Europe in the same mission.
Easily. Moving within an orbit is a matter of fine adjustment. For example, any stationkeeping that expands the orbit slightly will cause the satellite to "fall back" over time. Geostationary satellites are the best orbit for this, since every satellite in such an orbit essentially shares it with all others, differing only in position along the orbit.
I'm not sure this is true. if it were, there wouldn't be launch windows because any correction within a given orbit would be, as you call it, "a fine adjustment" yet we clearly do have launch windows.
Also if you're in a geostationary orbit to deliver one payload you have to leave that orbit to get to another geostationary orbit because there are other satellites in your way.
It is a fine positioning, which takes time. The launch windows get you to the right spot right away. Someone paying for a dedicated launch doesn't necessarily want to wait around to get their satellite operational. Someone launching for cheap on a rideshare might be willing to.
Reading this, I had a little laugh after reading the entire spiel about increasing intuitivness and the first point is renaming issues (universally understood) to "work packages" (what?).
Maybe it's just me :) overall it looks like quite the overhaul from its redmine roots. A lot of what I had to hunt for in paid redmine plug-ins years ago is just a core feature in OpenProject.
"Work package" is a pretty universal term in non-software project management, though a single WP could contain multiple todo items. I'm not sure whether it was coined by one of the frameworks like PRINCE2, but a lot of large/governmental systems use it (certainly the UK/Innovate, NASA and ESA, etc).
I would interpret "issue" as more of a general "thing that needs doing" whereas work package has a fairly specific meaning. I wouldn't want to use the phrase work packages as items in a bug tracker, for example.
It's been a long time, but looking at my email invoices it was Abacus[1] for modernizing the frontend and a bunch of plugins from redmineup[2] like Agile and Resource, which appear to be default OpenProject features ("Board" & "Planner").
I agree that the term "work packages" does not always fit. "Issues" doesn't neither. An "Epic" is not a an issue, in my opinion. I am curious which term you had on your mind.
It was a fairly unique architecture that had some pros and cons. In reality what made it a winner was the steep subsidy by Sony (units were sold at a loss, making the assumption you would buy a few games) and the availability (later removed) of an official Linux distribution.
Weirdly, not really in the US. The regulations are all a little pointless because it's a "self-regulated" industry. Look at the cyber truck - stuck floor pedals and trunk closer that cuts off fingers, or trivial to clone car fobs.
The article makes it sound like the only parser for URLS in the entire Python ecosystem is urllib.parse, regardless of which spec it supports. Hyperlink and Yarl are absolutely prior art here IMO, and at least deserve a mention in an article like this.
[1]: https://github.com/tktech/py_yyjson [2]: https://tkte.ch/py_yyjson/api.html#yyjson.Document.patch
reply