The real solution is to allow users to own their push solution, and for it to become more commonplace among apps to support alternative push providers such as Unified Push. Molly, the FOSS Android Signal client supports this configuration.
I've sat in classes where people at my table genuinely took pictures of the exam while the professor's back was turned (being kind to us and giving us useful information on the board) and uploaded the entire exam to the Gemini app.
Cheating is all around disheartening and is now incredibly easy with all the free multi-modal models around. Real active proctoring is needed and devices need to be confiscated during exams. This is common practice in many other countries.
My son is taking an AP chem class - he's doing really well, super interested in the subject. It's a difficult class, to be sure. Many of his peers are just goofing off and don't understand things. My son regularly tells me about people in his lab group that are cheating off his papers (and, I think, even his test). He tries to cover up answers, but it's not always possible to do.
What is even more frustrating is that the teacher knows this and does nothing about it. Maybe one could argue that, in the end, these students fail to learn and will get their just rewards. But it seems to me that the lack of immediate corrective action (eg, an F on an assignment) is a failing of the system.
What is even more frustrating is that the teacher knows this and does nothing about it.
When teachers are evaluated based on how students perceive them, and are in turn evaluated by others based on the grades their students receive, there's a perverse incentive/conflict of interest for them to allow cheating.
If I were your son, next exam I would physically move my desk to the corner of the room out of protest. He should also report everyone he sees cheating.
As someone who attended an elite school in the post-covid era, here was my experience:
There is relatively little stigma against cheating. Maybe in smaller seminars and classes with higher collaboration there is some, but much less so in large STEM lectures. Many of the incentives in classes where exams were online led to arms races and widespread cheating (without exaggeration, over 80% of the class). For instance, a certain math class I knew of had all grades based on remote and often asynchronous tests. Many people would cheat/collaborate and ace them, leading to the professor increasing difficulty (as scores were very high). This led to more cheating and so on. It got to the point where the problem sets had such difficult problems in this intro class that only a handful of people (who had taken advanced course work in high school) in the entire 100+ person seminar were distributing proofs for everyone else. Really not great dynamics all around and it's worth noting that my school does not have a reputation for being ones with an especially competitive and cutthroat culture.
That's a very interesting call out, the connection between gaming academics and (gaming) finance.
They both do have very concrete point systems with a parallel set of less-measured but very real externalities, don't they?
This brings me to a bit of a related story.
A family member of mine who attended Princeton and was an undergraduate Residential Advisor (RA) in the dorms responsible for care of freshmen recalled hearing a presentation in the early 2000s to parents of students from an academic dean or faculty member. The dean boasted to the parents how great their kids were, describing how each year in the last decade they kept adding more work to the students and the students kept rising to the challenge. My family member RA, very aware of the resulting stress the students were under was horrified. This family member thrived at Princeton and loved it, but is quite wary of trying to put their own children on a track to get there or go there.
This event correlates with the increasing fraction of students at Princeton going into finance which began in the early 1990s and which peaked in 2006 with 46% of students at Princeton going into Finance. I had not considered a correlation between student psychological stress and psychology of "gaming"/cheating and the psychological going into finance until your comment.
At that time, there was some sense that perhaps many Princetonians went into Finance because they had to pay of the huge loans from the price tag. After a couple decades on working on financial aid improvements, now that Princeton (tuition) is free for people with family incomes under $250k/year and has been for a while, and still large numbers (admittedly not quite as large) are still going into finance, I'm not sure some of the psychological factors around taboo topics like gaming/cheating and/or more prosaic related factors like reducing cheating while properly sizing the expected workload for the non-cheating population have been explored.
Intentional negligence? In many parts any reasonable looking into future should have made it clear things were unsustainable. Both on loan origination where rates would end up unsustainable for borrowers but also the derivative side with unsustainable liabilities. Screams of being intentional and negligent at same time, but it did make money.
In the past there was more of the expectation that if you were caught in a major scandal your political career would be over. In that sense there has definitely been a decline.
In my alma mater it was well known that business school professors were lazy and gave the same exams year after year, so all the fraternities kept backfiles of the old exams.
Since I was in the engineering school and most professors actually cared, it didn't affect us as much.
Usually the rule is you can't have a phone out of your pocket or backpack during a test. Students still have phones on them. If they disallowed that too, how would that work, an airport security style check going in?
When I had exams in the 90s we'd have to hand phones in at the start. If the phone was seen during the exam, your test would be forfeited. If the rules were that strict then, I can't imagine how they could be less strict now given how much more powerful phones are today.
Most colleges today will consider phone use during a test cheating, then it depends on the school but at least a 0 on the test is likely. I've had some professors say upfront that they'll go further and wreck cheaters as much as they possibly can.
They probably don't ask for phones upfront, but I don't see how that'd do anything. The only way to make this stricter would be to search students like they do for big standardized tests.
They do it for big standardized tests like the MCAT. If I went to school and saw this for every exam, I'd think wow I'm in a bad school, not that there's anything wrong with it per se but it's not commonly done.
That’s pretty sad. Even sadder is that those people will hardly even feel it to be cheating because they’re now using AI for absolutely everything and so suddenly contented with a situation where it can’t be used they still can’t help but use it. Not a good sign.
It's called "We just discovered Claude Code and so we think Anthropic is Amazing so everything they do is godlike and thus their design choices must also be god like. Apple is Dead, Long Live Anthropic" style.
Hm, I don't think this looks like Anthropic's design style. Anthropic is kind of doing a Chobanicore + Corporate Memphis design system that I personally find kind of creepy. But the website here just feels fresh and pleasant.
Agreed; that's a beautiful site. The main design style apart from minimalism that I notice is glassmorphism. Well, that and a very well chosen Monet to set the tone.
I am still so salty that Git won out for the average project over Fossil. Sure Git has some performance advantages for massive codebases like the Linux Kernel, but the vast majority of projects will never run into performance limits from their VCS. Fossil’s internal tools (wiki, forum, tickets<issues>, etc) are just so useful to have versioned with your code in one file.
I use Fossil for all my freelance work and it so easily allows me to get right back into the context of a project, niche details and agreements had with a client, etc. No need to pollute the codebase or gather together a million emails or notetaking software just to get back up to speed.
It can still change, I hate the notion that because Git is so culturally embedded we couldn’t ever switch. Fossil makes it super easy to switch and the workflow is actually easier coming from Git.
You can (and people did) do same kind of tooling based off git protocol and storage. Hell, even one for distributed code reviews.
It just... never was something majority actually want so they didn't really get any traction.
Issues wise you also get few nasty cases where you really do not want to keep it with project, like having clients send a bunch of screenshots or even videos of triggering some bugs can grow storage pretty quickly... and while extra few GBs on a file server isn't a big deal, keeping it with code repo just so someone can look at tickets locally is PITA, and you quickly get into "let's not use it, it just makes everything complicated and everyone repo bloated".
Someone could probably implement most of fossil features using git as backing store without all that much problems, the wiki/issues/whatever else features would just be separate, parallel branch hierarchy
Those screenshots and videos are taking up space SOMEWHERE, whether it be your inbox or your filesystem, why not have them as unversioned artifacts in your db? (Fossil supports this). Of course if you have multiple people working on it and many assets, other solutions would be better (shared cloud drives, etc). But for my use case of a storing textual information only (and perhaps a demo video, which many Git users often keep a video in their source and link it in the readme), Fossil works great to keep all my stuff together in the same context.
I explicitly dislike the idea of using Git as the backing store. Forget the fact that Git is not native on Windows and is immensely bloated; the actual .git folder is a mess for backup systems when working locally compared to a single database file.
> Those screenshots and videos are taking up space SOMEWHERE,
Sure but there is a big difference between being stored once (modulo backups) on a central server, and every developer needing to download all the resources for every issue and the entire wiki in order to work on the code at all. It works fine for sqlite, because they only have a handful of developers, so it's not a big deal for them each to have their own local copy of everything. But having to download GBs of issue and wiki data in order to make a pull request (however that would work with fossil) or otherwise contribute is a significant barrier to entry.
Not without having a degraded git experience like shallow clones, or using hacks like LFS or Xet, and then you're back at the initial problem of depending on "something else besides your repo".
I tried out like five or six of those back when they were trendy, and they all had one or more of these issues that made them unusable:
* Changes being tied to a commit (akin to git notes) so issues could have different status and comments on different branches. No overall view of the project.
* Using their own branches to separate from code state, which made a huge mess when looking at your branches or git history.
* Using a separate space (like git notes does, I forget what this is called), which isn't included in the standard push/pull.
* All of the above being distributed, issues in your checkout could be very different than someone else's, and now you have to merge those too.
* No non-developer UI for project managers to see or comment on issues.
Part of the problem is that fossil is very opinionated. It's great if your development flow is similar to that of the sqlite team. But it is very difficult to get it to work for other workflows. And in particular, fossil is designed for use by small teams and isn't really designed to be used by large organizations. This is even explicitly mentioned in the "Fossil versus Git" page (https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki)
I feel like part of that was timing. IIRC, when git was already stable and usable as a daily-driver, Fossil was still sometimes requiring that you completely recreate your repo when updating to a new version.
Git certainly had (and perhaps still has) worse user experience, but it worked and felt production-ready, with, of course, one of the largest open source projects in the world using it, and that made all the difference, perception-wise.
> It can still change, I hate the notion that because Git is so culturally embedded we couldn’t ever switch. Fossil makes it super easy to switch and the workflow is actually easier coming from Git.
I was exposed to Mercurial before Git and I stubbornly tried to advocate for it over Git for a while. BitBucket, at the time, gave Github a good run for their money and had great Mercurial support and was what I preferred.
I'm not really sure VCS were ever differentiated for there to be a wide world of them. They all solved the same set of problems so similarly that it felt, to me, that there had to be one winner. Right now most of the competition is in the Git Porcelain space.
N.B. I actually have a soft spot for darcs, which was my first actual DVCS. I just loved it so much more than svn and refused to use svn in college and used darcs to actually manage my projects and push them to svn after.
I'm still using Mercurial whenever I can (including work!). The Tortoisehg GUI is good for doing reviews, and the command line is comfortable.
I grew up on CVS and then Subversion. Played with Bazaar a little, mainly because it could use an SFTP location as the back-end.
And I still avoid Git if I can help it. I would/do figure it out when I have to, but it never feels comfortable. Such is my avoidance that I'm dabbling with Jujutsu although I'll still need to really sit down and read through it some more to grok the way it works.
My first distributed VCS was Tom Lord's Arch. I may have started early, but it took me a long time to understand distributed version control, thanks in no small part to Tom Lord, lol. GNU.
If it got proper tooling this would be true—but the community will need to build it. Darcs has more out of the box & more existing ecosystems to work with. Pijul is barebones by design, ready to be scripted, there’s just not much out there.
Yeah I've played around with pijul over the years but it's still not at a maturity level that I would like and at this point I'm not sure how the actual work behind patch theory is progressing.
When I tried Fossil it had things weirdly separated.
I was expecting when I make a commit, I would have the facility to specify what issues it addressed and it would close them for me automatically. It seemed there is so much opportunity there to "close the loop" when the issue tracker, etc and integrated in your VCS, but it wasn't taken.
This is a current architectural limitation, manifests (defining check-ins) and tickets are different types of artifacts and you cannot combine the card types into the same artifact. Changing this would likely break backwards compatibility with previous Fossil versions and I'd expect resistance. It may still be worth bringing up on the Fossil forum if you desire the feature.
Personally speaking though, I don't want things automagically closed GitHub-style based on parsing a check-in comment. An issue ought to be closed with intention.
> I don't want things automagically closed GitHub-style based on parsing a check-in comment.
Sure, I get that. I was just disappointed that none of the project management stuff seemed terribly integrated in any way from my brief review. It seemed like opportunities there that were not taken.
I wanted to host our company wiki in Fossil, but there is no way to import it because Fossil completely separates versioned project docs and the built-in Wiki function. Our git-based wiki could be imported into Fossil as "docs" but would not receive the nice formatting, GUI editor or dedicated page that the Wiki function does. There is also no benefit to manually converting it all to Fossil Wiki as some of our wiki editors work on raw markdown.md files and commit changes by git which is not possible with the Fossil Wiki; everyone would be forced to use the online editor only, whereas currently we have a choice of markdown or Gitea's editor.
I am a sucker for underdog software (anyone else using Ur/Web in prod?) and I was instantly infatuated when I first came across Fossil. I wasted a week of my life trying to fall in love with it but actually realising all the little things that make Git awesome. Beautiful diff output. Staging changes in hunks. Fixup commits, interactive rebase with autosquash. Git lets you treat not just your code as art but also your code evolution. In Fossil you don't get to clean up your branch into a coherent story. No, every path to and from dead-end blood-soaked alleys stays with you forever, unless you just don't commit anything until you have smoothed over all the details. No committing and pushing your WIP code to keep it safe (I mean you can, but you cannot then ever undo that). I'm sure other people feel very differently and that's ok. But Git's UX is on a completely different planet, imho.
Yes, I am someone who, when my branch code-wise is ready to be merged, I will still take however long it needs to clean the history into a coherent, bisectable set of patches.
To be fair, Fossil is kinda cool in many ways, but it's a downgrade for my dev UX. Also the configuration interface for access controls and suchlike to the repo server, issue tracker, etc. is... eccentric. I wouldn't be surprised to find some incorrectly/unsafely configured repos in the wild.
> I use Fossil for all my freelance work and it so easily allows me to get right back into the context of a project, niche details and agreements had with a client, etc. No need to pollute the codebase or gather together a million emails or notetaking software just to get back up to speed.
Hmm that's interesting to hear. I'm starting up a very small business this year (one guy selling shit at a craft fair booth) and I'm using plaintext accounting files in a Git repo for it. I wonder if Fossil could keep me from re-inventing some note taking and record keeping approaches. I'll have to look into what it can do.
It has a wiki, forum and issues included. So it definitely can do that, what fossil allows by default is to not have a docs/ or bugs/todo file, because its all in the server part.
I think this shows that you do not consider all build-up options here. Let me explain that.
Could something like github be made with fossil, aka fossilhub?
I believe the answer is ... in theory yes, in practice no. So this already means, if correct, the comparison between git and fossil is incorrect here. Fossilhub would not have dominated; git + github on the other hand did. Again, in theory a fossilhub could win over people to use it (and fossil), but people will compare it to github (back when github was still great) and become quite critical when fossilhub does not offer the same or similar set of functionality. At the least the core functionality - great issues + discussions, easy committing and changing of code and so forth.
Perhaps with enough resources, fossilhub could have conquered the world, but for whatever the reason, it did not, and I think this is in part due to the design. GitHub changed how people interact with repositories. They even made it easy to e. g. add files and change them online, at a later point in time. For instance in one project I am a co-maintainer and I rarely have to use the commandline; I can simply edit via the browser as it is. I don't think fossilhub would have done the same - actually, there is not even a fossilhub, so how would you want to compare git to fossil? It's not just the commandline code. Git has github; while it is a separate project, what does fossil have that people know and use?
> It can still change, I hate the notion that because Git is so culturally embedded we couldn’t ever switch.
We all have our dreams. All desert to become forests or agriculture may be a great idea. Effecting this is hard - but best luck to you betting on fossil here. I don't see it happening. Git raised the barrier here, even if only indirectly via github.
A key feature of github is you could bug report on many projects without registering an account for each one, this is not true of fossil. if fossil is to be taken seriously, then it needs a distributed auto id system, oauth or the like.
"Just use SQLite" feels like missing the forest for the tree (the pun being coincidence here). That is, certainly any database out there already use all kinds of very efficient structures to walk graphs under the wood.
Maybe Git has a more bespoke approach to its specific goal of source code as main topic to deal with, and finner layer of abstractions. Which could also explain the clumsy leaky interface it presents.
It worked on ipv6 only for like a year, it seemed to be back this last month but it seems to be back down right now probably because of this whole github ragequit happening.
Funny timing — I've been working on a hosted Fossil service to scratch this exact itch. The integrated wiki+forum+tickets+code is killer for small teams, but most people who'd pick Fossil don't actually want to babysit a server. So we host it.
Two things I keep coming back to:
(1) The "opinionated / small-teams only" critique others have raised in this thread is real, and I think Fossil should own it instead of fighting it. The 5,000-engineer monorepo market is a solved problem (Git won). Fossil should own the 1-50 person bracket — where having issues, wiki, forum, and code in one self-contained, syncable SQLite file is a huge unfair advantage.
(2) AI agents are a brand-new reason to look at Fossil that didn't exist when Git won. Every repo is a queryable SQLite file. An agent reads tickets + wiki + code + history with one SELECT — not 47 GraphQL calls and a rate limit. RAG and MCP setups against the repo become trivial.
I trust more a megacorp to survive more than 5 years than a personal host, I can't tell you how many times I've gone to a personal server where something I used was hosted and its dead.
there's a host your own version thats available now https://fossilrepo.dev live server (demo) in fossilrepo.io which is a modern wrapper UI. There's also the standard https://fossil-scm.org/ which you can also host yourself on a $5/mo server on Hertzner or the like.
Fossil is very easy to self host. If you already have a web server it needs maybe 10 or 15 lines of server config. If you want to avoid start up you need something to autostart/restart the server process. If you point it at a directory you can add a new repo simply by adding a Fossil file to the directory.
You can even run it on shared hosting as a CGI (never done it myself).
The only thing that took some setup was sending email notifications.
> The "opinionated / small-teams only" critique others have raised in this thread is real, and I think Fossil should own it instead of fighting it.
I agree I use Fossil for multiple personal and small projects. Anywhere I can, really. It is very simple and everything is distributed.
And backups. Sqlite makes it easier but no backup process is easy. You always have to backup and restore at least once to have the confidence to rely on it.
It's another (big) point towards paying someone else to host it.
a lot of other commenters point out the dead connotation, so you could pivot the semantics and go for something like fossil.fuel? has some "oomph" to it, and represents a high energy density carrier, a feedstock that can go in many directions, oils, plastics, ...
being a software project makes the environmental connotation less important (using a different project would also cost server energy etc...) so its more clearly tongue in cheek
Genuinely how are you supposed to make sure that none of the software you have on your system pulls this in?
It’s things like this that make me want to swap to Qubes permanently, simply as to not have my password manager in the same context as compiling software ever.
We run everything NPM related inside Apple containers, and are looking to do the same with Python and Rust soon. Bwrap on Linux does the same.
I like to think of it like working with dangerous chemicals in the lab. Back in the days, people were sloppy and eventually got cancer. Then dangers were recognized and PPE was developed and became a requirement.
We are now at the stage in software development where we are beginning to recognizing the hazards and developing + mandating use of proper PPE.
A couple of years ago, pip started refusing to install packages outside of a virtualenv. I'm guessing/hoping package managers will start to have an opt-in flag you can set in a system-wide config file, such that they refuse to run outside of a sandbox.
The problem is that package managers are a distraction. You have to sandbox everything or else it doesn't work. These attacks use post-install hooks for convenience but nothing would have stopped them patching axios itself and just waiting for devs to run the app on their local workstation. So you end up needing to develop in a fully sandboxed environment.
While it's not perfect, pinning specific versions and managing all updates directly has been a solid solution for my team. Things can of course still slip through, but we're never vulnerable to these just because there was a new package release and we opted into it by default.
Updating packages takes longer, but we try to keep packages to a minimum so it ends up not being that big deal.
This sounds like satire but isn't - I just make sure the nodejs/npm packages don't exist on my system. I've yet to find a crucial piece of software that requires it. As much as I love that cute utility that turns maps into ascii art, it's not exactly sqlite in terms of usefulness.
I don't deny that node/npm is useful for building servers, devtools for JS development itself, etc. but as an end user I haven't encountered anything useful which requires having it on my machine.
Hello. You missed the point I was making drastically. Of course for software that I build personally I can do all that, but not for all the random stuff in my system that I’m trusting maintainers to package for me, or otherwise good PKGBUILDS in the AUR. You physically cannot have the bandwidth to be on top of these supply chain issues all the time.
Also, semantic versioning is not some golden goose that fixes this issue, update embargoes help, but that doesn’t require semver. Vendoring dependencies is not a scalable solution for all the software people use.
My router doesn’t have a WPS button, so I also had to use the two button interface. Not fun having to cycle through some 50 plus ASCII characters for the WiFi password. I’m pretty sure you can emulate the button press in openwrt with some package though. It was faster to just enter the password than to figure all that out.
I just use HN as my comment platform. I have a Hugo short code that (very respectfully!) grabs the comments on a full rebuild, but only if those comments are not already cached and if the post is less than 7 days old. The formatting looks quite good on my site. Feel free to check it out at the bottom of this post: https://mketab.org/blog/sqlite_kdbx
The main critique I’ve seen of the duress pin is that it causes undue trouble. The obvious counter argument is that if you genuinely have the need for a duress pin, it’s worth its weight in gold. If the severity of the charge or physical punishment (in countries without due process) would in any way be less by NOT having xyz data on your phone, then it’s helped. Say, the difference between 10 years for destruction of evidence and 80 years for espionage.
Even when used against a government, there are a lot of different gradations. E.g., my government is not very hostile, but people who get arrested at a demonstration might still want to erase their phone. There are some countries where someone is not required to give their PIN, but the police is allowed to investigate a phone if they can unlock it by other means (Cellebrite, face unlock, etc.).
By the way, another way GrapheneOS protects against this is by allowing automatic reboot after a period without unlocking, which can be set to a very short period. This puts the phone in BFU (before first unlock), where fingerprint and face unlock do not work, and the phone is much harder to hack with tools like Cellebrite.
For sure, but these LARP situations are mostly based on defending against a highly motivated and powerful entity like the government.
But other situations like against thievery, domestic abuse, or brute force deterrent (ie: setting a simple duress code that is likely to be triggered, say 1111), it has the potential to work well.
Graphene brings out some of the best of android. Profiles are first class citizens, private spaces within the owner profile (I think all profiles can have them now?), and app pinning are great.
reply