LaTeX absolutely sucks for proofing. Typos end up being buried in tags, and you end up with a document that looks pretty but possibly not fully edited.
If you are collaborating with advisors, they may wish to add comments to your copy as you work through your thesis. There is no clean way to do this in a TeX source file, so the only way to do this would be to export your work-in-progress into a DOCX, and then work your changes back into your source.
Versioning-by-hand sucks balls. When you’re approaching various deadlines with other obligations at hand, all open-source kumbaya ideas go out the window and you just make do.
For your manuscript_final_FINAL_v2.docx file, manual layout tuning ends up being not too bad and likely takes less time than troubleshooting LaTeX which might not have as much documentation.
Don't most people use git for their latex (or even markdown) version control? All the tools that have been developed for code collaboration work really well for documents compared to messing around with word's undocumented format and binary blobs.
Last time I wrote anything remotely academic was several decades ago, but at that time, the argument was that you had to use LaTeX because Word documents had no support for simultaneous editing, version control, and editors comments. It is truly bizarre to see the same arguments repeated after so long time but completely reversed, in favor of Microsoft Word. Surely the tools haven't become worse over time, given the popularity of github, Overleaf and such?
Disagree. Hunspell and aspell have tex modes that understand well what needs to be checked and what doesn’t.
Comments can be added with ‘%’. Just make sure to have a linebreak at every sentence and it’s cleaner than anything. Services like overleaf also exist for collaboration.
You can use any versioning system you want. From git to dropbox, its plaintext.
I do agree that layout can be very time consuming, but it helps once you learn to not care about it till the absolute end of working on the content.
It isn't realistic to teach your collaborators a new system just for your own comfort. They'll just avoid making edits/comments. Especially if you're just a PhD student/postdoc interacting with a full time scientist - who will have much more work to do than fiddling around with your esoteric editing system.
It's kind of the same issue that FOSS enthusiasts often miss regarding other things, eg. most gamers wouldn't waste their time fiddling around with WINE settings to get things to run in Linux, the solution wasn't to tell them to just install something extra and do things different, it was to improve the infrastructure such that very little fiddling is needed in most cases.
My experience has been that there's somewhat of an age divide. I've noticed that fellow junior academics are far more likely to prefer LaTeX, while all senior collaborators I have ever had, preferred Word. So I end up using Word for everything to ensure that it is easy for them to edit/review the paper.
Word is good for collaborative editing, but not very convenient for version control (and version control is very important when using AI assistance). So lately my strategy is to draft in Markdown, then copy over to Word once the draft is at a point that I might be okay sharing it with collaborators.
Even if you write your thesis in latex, all interaction with the administration, grant applications etc. still happens in word documents. Thank God/John MacFarlane for pandoc.
I wonder if a technique to pack crazy high amounts of heat in a small mass and just eject it in an orbit to the sun would be viable. Probably not, but the idea of a datacenter pooping its heat into little pellets is quite entertaining. Like Lila's pet from Futurama.
You assume billionaires and politicians are all-powerful and that they congregate in a secret cabal voting on where to take civilization next. No they live in fear of what other powerful people might do and their reactions to what is perceived risk can really f up everything. Even the most powerful autocrats in the world have to deal with other countries.
Framing it as some Illumianti-like dark room cabal is the wrong way to think about it.
Look at our present woes in the Middle East. We have two nuclear powers who are dragging the world towards economic collapse. I believe that before we reach that economic doomsday scenario or anyone seriously considers deploying nuclear weapons, the money behind those powers will oust those who try to push us past the brink.
To this point, I believe there's a very real possibility that Trump gets 25A'ed next year, meaning the 25th Amendment is invoked to remove him from office.
icbms and hypersonics exist, theres no defense against the top end anywhere atm.
if you're in a war where people are shooting your satellites out of the sky you're past the point where defenses matter. theres no grey war in space like russia hiring people to blow up stuff in europe and very few states could take out multiple satellites in space.
beyond that if we ever did get to that point, you could develop anti missile tech in space, you effectively have the high ground sitting at the top of the gravity well.
I'm reasonably sure there are more states that could destroy a satellite than hit infrastructure on US soil. And if you try to use an ICBM to hit the US then you risk getting nuked.
> people are shooting your satellites out of the sky
If space powers have any sense at all they'll develop a fleet of satellites that deploy small limpet craft that attach to the enemies' satellites and drag them toward earth.
Literal shooting sounds like mutually assured satellite destruction.
This. Orbital debris are an area denial attack, and since there's only one shared planetary orbit (in aggregate), debris-creating weapons are more like biological weapons, poison gas, and tactical nuclear weapons. Even if you win, you've impeded yourself.
The internationally hoped for outcome should be that China continues scaling their orbital use, to the point where it becomes mutually advantageous to sign a treaty with the US banning orbital debris-creating weapons (and ideally imposing mutually-supported consequences on non-signatories who breach the agreement).
Then everyone would be left with more sane options of disabling-only (microwave, laser, targeted EMP, etc).
It's really about bandwidth and availability - US satcom systems were really struggling, and the only truly global (Iridium) was quite low bandwidth. Starlink is essentially "Iridium with newer tech and mass production" and IIRC DoD through various fronts put quite a lot of early financing to make it a thing, even if later the networks were supposedly disaggregated (would make sense to start building separate one once PoC was proven)
DoD financing for Starlink was a long term game to create pLEO sensing capabilities: initially GMTI, then AMTI.
Both of which give the US military more persistent (revisit delay near zero because number of assets) and survivable (number of assets + LEO debris characteristics + cattle vs pets) ISTAR.
And an advantage in persistent ISTAR is a key enabler of the way the US military is aiming to fight a peer state adversary.
I'd be fascinated to dig into the contracts, but at 10,000' it's DoD offloading the bulk of the development cost onto NASA and the public (which in both cases, still gets good value for money).
Yeah similar to the AWS data cneter getting trashed in UAE by cheap drones and short range missiles. I think only 3 states have the capabilities necessary to knock out satellites , and one or two others with latent potential.
For the rest of the planet its basically untouchable unless theres more wisespread proliferation in missile tech.
One of my main motivations as a leaf node in the org tree is to try to make my job the least annoying possible. Meaning spending time making sure things don't annoy me in the future (like cleaning up code, updating legacy systems, fixing bugs in ways that ensure they won't happen again).
Not necessarily so I can work less (afterall there is always work to do as a developer). But so I don't get annoyed.
Usually that ends up saving time for the company, but not always.
Not always, but overall having cleaner code with less bugs, more documentation and tests, is not just an annoyance to you. It's a money-maker for your employer as well in the long term by virtue of reducing burnout rate, decreasing onboarding time, making any improvement possible at all...
I get it, but my incentives are deeply misaligned with the company's in this regard, I prioritize things that annoy _me_ directly or indirectly (through not having to troubleshoot bugs made by other people).
On a ROI and prioritization metrics I put myself first, co-workers second, product third, company bottom-line fourth. Part of putting myself first is delivering things mandated by management (so, you know, I don't get fired) which skews to product and company bottom-line, but things I do of my own volition is definitely not going to the bottom-line/product.
I am lucky I am not time tracked aggressively and that my immediate superior lets us work on things out of our own volition. The fact that some of the stuff I do benefits the company indirectly is secondary to my motivation to do it.
I run the editor (and its extensions), my projects and any agent harnesses from inside a container and use that extension to get an editor.
This is mostly to protect my credentials and data from malicious extensions/dependencies/rogue-agents, bu it also lets me quickly port my dev environment to any machine (I use linux at home and macos at work). Just install podman, install VSCodium, add the SSH extension, build image, add my utility shellscripts (to quickly get in and out of the container in a shell) and done.
Apparently Microsoft keep some VSCode APIs proprietary so only its own extensions can use it (allegedly for security reasons), which is why this specific extension only works in VSCodium. I wonder if it is vulnerable to the same things the article points out.
I used VSCodium before and found it to be a massive waste of time for no benefit. A significant number of extensions either aren't in OpenVSIX (or whatever it's called), or don't work for some reason.
Just disable telemetry in VSCode and you're good.
Yeah, but to be honest on my current project the only extension that I needed, but wasn't available was the Typescript 8 support (the typescript with golang-based language-server) which should land eventually in the built-in typescript support.
My company did this a couple of years ago to some machines we host ourselves. It is a bit of trouble to set up but it is not that bad and can easily save a 1000+ dollars per month since GHA runners are very expensive.
It is that grey zone where it is kinda worth it to pay someone to do it, but also might not be worth it the headaches of managing that person and the infra (like what happens if they go on vacation). The improved speed is the thing that tilts the balance.
To be fair they are also really good at fixing the tests and the whole point of a test is that when it breaks you need to take a look.
It is more like looking at test diffs is more valuable than looking at new tests.
But yeah, I wish people would clean up LLM-slop a bit and remove some useless tests, but I think this status quo is actually better than no tests at all.
Are people really making hundred-pages thesises in Word?
I suppose it is not that bad if you don't have a lot of charts/pictures/formulas, but still...
reply