On Wed, 22 Nov 2017 21:35:31 -0700 Warren Young <[email protected]> wrote:
> The Fossil vs Git UI situation has been studied before. There’s a > tremendous amount of logical mismatch between the two, such that > commands for one often cannot be translated 1:1 to the other. > > Just as a single example: > > $ fossil ci > > is not at all the same thing as > > $ git commit > > A better approximation is: > > $ git commit -a && git push > > And even then I’m sure I’m missing some details. > > Now, here we have an example where Fossil is far clearer, as is the > typical case, but that won’t make all the Git fans you show this to > squee and insist that their projects switch to Fossil. > > I’m reporting results here, not speculating. I’ve tried it, and some > kind of dismissal is almost always the result. Why do you suppose > that is? I'm not saying there's anything wrong with the UI. In fact one of the biggest reasons I started off with Mercurial was that Git was unusable for me at the time. Then I came across Fossil which worked even better than Mercurial. UI wise, Fossil is a clear winner in my books. However my books aren't someone elses' books. > What keeps these people using Git are network effects. Most people > decide that it’s better to put up with its horrible CLI or tie > themselves to proprietary GUIs/web services — most prominently, > GitHub — rather than lose out on all the benefits they get by being > in the Git world. > > We’ve been to this party before. Linux vs Windows, > Pascal/D/ObjC/Go/Rust/... vs C, etc., etc. “Better” doesn’t always > win. And in that case, adding Git support to Fossil is unlikely to increase its user base much. I vaguely recall Mercurial trying that, and this didn't help them much, even though Mercurial is much easier to use than Git. > I’d say I have normal users: they want maximum results for minimum > effort. > > As do I. Since I run the project server, what I say generally goes, > but I ignore my users’ wishes at peril of losing my user base, thus > risking a waste of my time writing software that no one will use. > > There is not black or white here. There is only gray. They want maximum results for minimum effort? That may be normal, but it's still whiney. Everyone wants this (that's normal), but it's a difficult balance here between maintainability and servicing users properly. > > > Fossil supports downloading entire > > checkins in zip and tarball archives > > I often end up hand-constructing such URLs for my users to click, > because they can’t be bothered to dig through the UI to figure it out. > > Here we have a case where Git is actually faster and clearer: > > $ git clone https://example.com > > vs. > > 1. Visit https://example.com > 2. Click Timeline (and how would my users know to do that?) > 3. Click checkin ID. > 4. Find and click Tarball link > 5. Unpack the tarball > > Then they must do all 5 steps again every time there is a new version > they want, vs: > > $ git pull I agree with Zoltan's assessment, in that this is exaggerated. You can just give users a direct link: https://example.com/tarball This gives them the latest tarball every time. The second step on the user's part is extracting the tarball: $ curl https://example.com/tarball | tar xzf - > Fossil often can’t get to the simplicity of Git here for two reasons: > > 1. Fossil may not be in the end user’s stock OS package repo. (e.g. > RHEL, CentOS.) > > 2. If it is, it may be far too outdated to even work with the central > repo. (e.g. Debian, Raspbian.) > > Thus we have to point users at precompiled binaries or instruct them > in building from source, all of which makes Fossil look even more > complicated than Git, when day-to-day, the reverse is true. But you > only realize that *after* you get Fossil up and running on your > system. With all these odds stacked up against Fossil's favor, adding Git/Hg support as per the proposal is not going to help at all. > I’m just cheerleading here. It’s drh’s call what he spends his time > on. I trust his judgement. As much as I agree, this kind of attitude does very little if gaining extra users is what he wants to do. Then again, perhaps he's not too bothered, which isn't a bad thing per se. > By controlling variables, as any good scientific experiment does. > Here, that means using the same filesystem, disks, etc. If Fossil is > reworked to use a Git-compatible pile-of-files repository format and > performance doesn’t improve, then either: > > 1. That wasn’t the source of the difference, so now we can check it > off the list of things to look at; or > > 2. There is an important difference in the implementations, which > will now be easier to find, since both code bases are trying to > achieve precisely the same end. > > Contrast the state of things today, where comparisons are almost > pointless, because Git and Fossil are comparable only at a skin-deep > level. They’re both DVCSes, and that’s about the extent of the > similarity. How then can you know why one is faster than the other? It may be easier to implement Git in an SQLite database for the sake of comparison. Your point is valid especially with the rise of high-speed SSDs (NVMe and what not). > There’s a wide rainbow between my 4 kWord C compiler and modern GCC. > > It wasn’t that long ago that I worked out a plan, here on the mailing > list, for a way to get a good portion of Fossil onto a PDP-11. I > didn’t get any responses that told me why it was impossible. > > I suspect you have too narrow a view of what being in one’s right > mind is. It takes all kinds of crazy to make up today’s F/OSS world. Indeed. Crazy = not in the right mind. Nothing wrong with being a little crazy, considering the sort of junky people I've met in my lifetime. But it is important to be realistic, and Fossil/SQLite should not be coded just because a small minority will use it in corner cases like this. > > As for that particular C compiler you are using, it is broken. > > Therefore…what? No good work can be done with such compilers? The > platforms they support must be relegated to the dustbin of history? > > Would you write off the entirety of the retrocomputing and > retrogaming movements plus a good chunk of the embedded space just to > defend your idea of what a “good” C compiler must be? Perhaps I worded it poorly. What I meant was, is that compiler is no good for building modern applications like Fossil. A better example: if you were trying to screw something using a hammer, would you like the manufacturer to make screws that can be installed using a hammer just for your corner case, or would it be better just to use the right tools for the job? > > I’m all for standards and progress, but I also recognize that we > cannot always drag elements of the past up to current standards, and > that there is value in past systems and purposely limited modern > systems. You should ask the OpenBSD folk for advise. They have run on super unusual systems with compilers that support C99, including the VAX. > Much of the problems we’re having with IoT these days comes from > trying to put a 32-bit processor running a multitasking GCC and Linux > based OS into lightbulbs. Actually the real problem with IoT is that people think they need 32-bit internet-connected light bulbs to begin with, and companies making shoddy internet-connected devices are selling these "smart" gadgets as a must-have tool. Some are quite pointless too, like Google Home for example. Or that wi-fi connected juicer that cost $600. > I expect I could get SQLite and Fossil to run on a PIC32, for > example. The current version of Microchip’s XC32 compiler for that > chip family only supports C89 and some C99 features. It also > supports up to C++03, which means it might implicitly understand some > C11 as well, but certainly not all of it. I don't think at this stage a lot of the C11 standard is necessary for Fossil's codebase to become a bit cleaner and more, well, standard. Just some of the features I mentioned would make things a lot easier to maintain and provide optimisation opportunities for compilers. > I don’t need to do that today, but I’d prefer that you don’t preclude > me doing it in the future just because you want to require C11 to > compile SQLite and Fossil. It won't preclude you doing it if you try hard enough. All I am proposing here is basic C99 functionality such as postponed variable declarations, inline/restrict (maybe), stdint.h/stdbool.h, etc. to make the code neater. If your compiler doesn't support some of that stuff, #define is your best friend. > Infrastructure software should live by different rules than > user-facing software. If you are developing software for a company > whose marketing department decides that targeting only Windows 8 and > 10 is the best decision, then by all means, use C11 or C++14 > exclusively; you can afford it. Using C99/C11 doesn't require Windows 8/10 or Linux. It is just a C language standard, not an API standard or minimum OS/system requirement. > More interesting are platforms like the PDP-11, SNES, etc., which > require simulators/emulators to run software for those machines on > modern hardware. Programmers wanting to produce new software for > those machines must either use compilers of the day or retarget > current tools for them, often dropping features along the way to > squeeze into the old footprint. This is all interesting from an academic perspective at least. I recall a presentation by Andrew Tanenbaum (of MINIX fame) mentioning that software is becoming slower and larger at a faster rate than hardware is increasing in speed and capability. He compares running a word processor on the PDP-11 to running MS Office on modern Windows. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
