KEGS v1.11 released

[Kent Dickey]

I've updated KEGS, an Apple IIgs emulator for Mac OS X and Linux, to 1.11.
The Mac executable should run on 10.13 or later. It's also a universal app,
so it runs native on Apple M1 silicon. There's a Linux executable as well.

KEGS v1.11 is available at: http://kegs.sourceforge.net

The current CHANGES.txt file:

Changes in KEGS v1.11 since v1.08 (08/19/21)
- KEGS should support many international keyboards, converting your local
keys to the US equivalents: [,],|, etc. Italian works least well,
sorry.
- KEGS can choose character ROMs out of a ROMX-compatible file. Use F4,
"Character ROM Selection", and then pick the file and font.
If you pick an unreadable font and cannot undo it for some reason,
quit KEGS, and using a text editor, delete g_cfg_charrom_* lines from
config.kegs.
- Taking an IRQ logs the stack accesses in the datalog properly.
- Fixed BRK and COP exceptions to always pull their vectors from ROM.
Bug was found by Applecorn: https://github.com/bobbimanners/Applecorn

Fully source code is included. To rebuild on the Mac, all you need is
to download XCode and type "make".

Kent

[Christopher G. Mason]

On 8/19/2021 6:08 PM, Kent Dickey wrote:
> I've updated KEGS, an Apple IIgs emulator for Mac OS X and Linux, to 1.11.
> The Mac executable should run on 10.13 or later. It's also a universal app,
> so it runs native on Apple M1 silicon. There's a Linux executable as well.
>
> KEGS v1.11 is available at: http://kegs.sourceforge.net
>

Kent,

Is it possible to start using source code management? I'd like to track
some the 1.x changes to the KEGS core in order to update GSport. Most if
not all the changes made thus far should merge into GSport (which mostly
has bug fixes to the v0.91 core and emulated I/O device additions).

[Kent Dickey]

In article <sfn3om$jfh$1...@dont-email.me>,

I have no plans to start using Git. KEGS source arrangement is pretty easy
to drop into any source code system.

Kent

[David Schmidt]

Yep, Christopher, we can do diffs against code trees to get close -
won't be as convenient as in git, but perfectly serviceable.

[Michael AppleWin Debugger Dev]

On Friday, August 20, 2021 at 7:29:38 AM UTC-7, Kent Dickey wrote:
> I have no plans to start using Git. KEGS source arrangement is pretty easy
> to drop into any source code system.

That's a shame to hear. Obviously the final decision is yours but I have found git, and GitHub, to be a complete game changer -- managing PR (pull requests) via GitHub is almost trivial. Visual diffs are automated.

I would highly recommend taking the time to learn git if you haven't already and are a professional programmer. I found the basics of git trivial to learn but others say it is difficult. YMMV. Once you have a good cheat sheet it becomes much easier to understand the differences between stash, workspace, index, local repository, upstream.

**cough**
https://github.com/Michaelangel007/git_cheat_sheet

m.

[Kent Dickey]

In article <9e7848a3-6da7-4325...@googlegroups.com>,

Git makes very complex revision control tasks possible. That's great! It
also makes simple, easy things complex. Boo!

You're not the first person to try to say Git is great, without being able
to express that in a convincing way. How is a chart of 74 commands simple?

My build environment is structured around building fast and easily. Revision
control is a distant thought--it's nice for diffs and for a written history
of the code, but it's much less important than building. Note that I
wrote my own revision control system and build system, and so I like it.

Kent

[Michael AppleWin Debugger Dev]

On Saturday, August 21, 2021 at 9:42:14 PM UTC-7, Kent Dickey wrote:
> You're not the first person to try to say Git is great, without being able
> to express that in a convincing way. How is a chart of 74 commands simple?

You're assuming that all 74 commands are used/needed in daily operations. They are not. I have over 200+ git repos and if I were sort the git commands by my usage over the last 7 years of using git I would hazard a guess at placing the most frequently used in this order:

* git status
* git diff --staged (along with other variations such as: git diff)
* git commit -m "reason foo" (along with variations such as: git commit --amend -m "Corrected foo")
* git add -p
* git push
* git pull
* git log -#
* git show
* git checkout -b foo, and git checkout foo (along with variations such as: git checkout head^2)
* git rebase, or git merge. (If you are the only developer on a repository this isn't even needed.)

These 10 commands will get you 97% coverage for basic version control for git.

These two git commands are also done once per repo and will get you 98% coverage for basic version control.

* git clone
* git init

I would add these lesser used commands will get you 99% coverage for basic version control.

* git cherry-pick
* git bisect

A total of 14 commands isn't TOO complex. The "daily 10" is certainly manageable. How many commands does a typical version control system need for daily operations? 5?

The astute reader will notice I have used the qualifier "for basic version control". I would place git usage into 3 main camps: beginner, experienced, advanced. Once you find yourself needing to use git bisect you are starting to move beyond beginner usage IMO.

While you are correct that git has a LOT of power -- you are assuming you need to master 74 commands before you can be productive in git. That is false. Most of that power _isn't_ need to be for basic operations but you will find that as you use git more and more you will start to make [more] use of the more experienced commands such as git reset, git stash, git log --follow -- filename, etc.

Git provides a lot of power because as professional developers there are many scenarios where we need to inspect, modify, search, the history tree. Fortunately most of the power git provides isn't typically needed for day to day operations. The nice thing about git is that it scales from beginner to advanced. You will probably never "outgrow it".

Git _can_ have a difficult learning curve but like when learning any new tool you start small with your usage scenario. As you get more comfortable you expand the tool's usage. Git is like a swiss army knife. Due to its popularity there are hardly any scenarios where developers haven't thought of a solution. I'm NOT saying all those solution are clean, sometimes they are extremely messy, but for usage scenarios git certainly covers a lot of ground!

If you are just a hobbyist programmer then yeah, don't use git (or TortoiseGit, etc.), but at least use SOMETHING for version control such as TortoiseSVN, etc. or whatever you find easy. Not using _any_ version control, even for small/toy programs, is pure madness.

If you are a professional programmer not knowing git in this day and age is almost corporate/career suicide IMHO. There is a reason almost every other version control systems sucks and why git took the world by storm. i.e. I've written code while on an airplane and sync'd it back up once I was back in the office -- git makes this painless. A distributed version control system is a game changer. Even if working alone "git add -p" has _completely_ changed the way I do development. "Commit early, commit often" isn't just a meme. It greatly simplifies regressions.

As a professional games developer there are certain things that are deal breakers:

* Having less than 4 monitors on my primary dev box,
* Not using a distributed version control system, such as git,
* Not using a professional keyboard,
* Not using an ergonomic chair, and
* Not using wrist rests and/or an inclined trackball.

The "pain" isn't worth it. I'm certainly no git expert but looking back at the 7 years I've been using git whatever little bit of pain git introduced the power is completely worth it. "git bisect" is amazing for finding when a bug got introduced, or the reverse, when a feature stopped working. Which reminds me, I still need to upload my git repro. on using git bisect. =P

I'm not saying git is perfect. It is not.

* It is utter garbage for storing binary files -- which massively bloat your repository -- but it wasn't designed for that usage so it somewhat understandable.

* We've discussed the learning curve above.

The point is that while git certainly CAN have a difficult learning curve but it doesn't NEED to have one. Any version control system is going to have a learning curve. Whether that be checkout, lock, checkin, or git push/pull/add/commit it is going to take time to learn good practices. In programming I have two regrets:

* Not using gvim earlier, and
* Not using git earlier (or even just using any version control system for personal projects.)

I can't even begin to think of all the years I wasted using inferior tools.

When AppleWin moved off of Berlios to GitHub at the time we didn't know how that would pan out. Looking back that was a REALLY GOOD decision -- it has streamlined our development process. This is important since for everyone on the team AppleWin is "just a hobby". GitHub's PR feature makes merging code quite painless since you can do all of it from the web interface. The ability for users to create issues, have automatic references to commits or other issues, for visual diffs, are really, really nice. If you need to interface with other developers and users, GitHub does a pretty good job of making it easy to manage code.

Not all git tools are the same. Stay away from BitBucket as it lacks basic features that GitHub does. For git clients, I will refrain since everyone has their pet favorite.

Out of all three options:

* Not using any version control
* Using a non-distributed version control, such as TortoiseSVN
* Using a distributed version control, such as git.

The last one, for my needs, wins by a landslide.

"Sales pitch" mode off. /s

m.

[fadden]

On Saturday, August 21, 2021 at 9:42:14 PM UTC-7, Kent Dickey wrote:

> Git makes very complex revision control tasks possible. That's great! It
> also makes simple, easy things complex. Boo!

I would argue that it doesn't actually make most *tasks* more complex. The common CVS/Perforce approach is simply more natural: you check out a file like you would a library book, and sometimes you have to merge the contents. Once upon a time, I had a few colleagues who disliked the added complexity in Perforce, preferring the RCS model where you had exclusive access to the files you wanted to modify. Git requires you to learn a more complicated metaphor that allows distributed rather than centralized control of the contents of the tree. Once you get that sorted out, the everyday stuff doesn't feel much different. (Just don't try to change the checkin comment on a change you've pushed.)

The only commands I use frequently are "git commit -a" and "git push", with the occasional "git add" when I create a new file. Once you understand what it's doing under the hood, the question stops being "OMG why does git reset have all these different forms?" and instead becomes "OMG why couldn't they have named these things in less-obscure ways?"

The real advantage for me was less about git per se and more about github (or gitlab). SourceForge is a festing pile of adware stacked on an awkward UI. git*b is actually pleasant to work with. Part of why these sites work is that git distributes the load, so you don't need significant resources server-side. (Google used to have a *massive* Perforce server, for pretty much all company source code. It was slow and created a single point of failure. Last I checked it's all git now.)

github serves the source code (as individual files or tarballs), provides a fast and convenient site for downloading the pre-built binaries, and hosts the web sites: a2ciderpress.com, nulib.com, and 6502bench.com are all hosted there.

> My build environment is structured around building fast and easily. Revision
> control is a distant thought--it's nice for diffs and for a written history
> of the code, but it's much less important than building.

I've used "git blame" any number of times to try to figure out when and why I did something. I've also reverted to the repository copy a few times when a change I was experimenting with turned out to be the wrong idea. I've got my personal web site in a local git repository. It's nice to have an "undo" button. :-)

I don't understand why building and revision control are competing for resources.

[Kent Dickey]

In article <f371e249-19b5-440e...@googlegroups.com>,

Michael AppleWin Debugger Dev <michael....@gmail.com> wrote:

>On Saturday, August 21, 2021 at 9:42:14 PM UTC-7, Kent Dickey wrote:
>> You're not the first person to try to say Git is great, without being able
>> to express that in a convincing way. How is a chart of 74 commands simple?
>
>You're assuming that all 74 commands are used/needed in daily
>operations. They are not. I have over 200+ git repos and if I were
>sort the git commands by my usage over the last 7 years of using git I
>would hazard a guess at placing the most frequently used in this order:

[snip]

Again, you make a long argument for a revision control process. I have one.
I just haven't made it public, but a glance at KEGS code shows it's based
on RCS (you can see the revision numbers in the source files). RCS is
terrible, but with some wrappers, it's workable. It has some advantages.

You make a case for GitHub (which is a superset of Git, and where many of
its useful features are not really Git at all) for distributed projects.
I would like a browser interface to view the current source files, and
sourceforge cannot really do that (well, without me learning something else
that looks like GitHub but isn't), but this is not a high priority for me.

Kent

[Michael AppleWin Debugger Dev]

On Sunday, August 22, 2021 at 9:43:37 AM UTC-7, Kent Dickey wrote:
> RCS is terrible, but with some wrappers, it's workable. It has some advantages.

If a 1st-gen VCS if works for you more power to you but there are reasons the world has switched to 3rd-gen VCSs even for single developer projects.

RCS is archaic garbage. In the ~40 years since 1982 there have been significant developments to version control.

> I would like a browser interface to view the current source files

Any modern repo hosting site will do that.

m.

[Nicola]

> On Sunday, August 22, 2021 at 9:43:37 AM UTC-7, Kent Dickey wrote:
>> I would like a browser interface to view the current source files

I find Fossil (https://fossil-scm.org/) better designed than Git, and
I prefer it for most of my projects, unless Git is a requirement upon
me. It integrates a web ui, which can be used to do almost anything with
your repository, including viewing each committed source file and, of
course, their history (also in ways that are not possible in, say,
GitHub).

If by "current source files" you mean the current checkout (changes not
yet committed), those are manipulated through the command-line, although
`fossil diff --tk`) will open a graphical diff.

Running a self-hosted server is trivial, but one may also rely on (free)
third-party services, such as ChiselApp. In any case, you keep control
over *all* of your data, including tickets and discussions. How do you
move away from GitHub or GitLab without losing such information?

For those familiar with Git, I'd recommend this document:

https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki

Fossil has *lots* of features (among the rest, it can also import from,
and export to, Git), but getting started is relatively easy (see the
Quick Start guide). I'd only mention that it makes it *really* difficult
to lose your data. Whereas in Git you can easily shoot yourself, e.g.,
with something like `git reset --hard`.

Nicola

[Kent Dickey]

In article <30c9ef1a-7087-422d...@googlegroups.com>,

Michael AppleWin Debugger Dev <michael....@gmail.com> wrote:

The Apple II is archaic garbage, yet here we are emulating it. Vi is
archaic garbage, and I happily use it every day.

I am not familiar with your terminology, so I googled it. A 1st gen tool
is "no networking, single file with locks" and an exmaple is RCS; a 2nd gen
VCS is "centralized repo, multi-file, merge before commit" and is CVS/SVN;
and a 3rd gen is "distributed repo, commit before merge" and is Git/Mercurial.
My VCS is gen 2.2 or so. It has features Git doesn't have that I find
valuable.

These arguments seem to mostly be insulting me. How do you know what I'm
doing? You know, it's possible to write a version control system that
worked exactly like Git in terms of interface and commands, and yet had RCS
underneath it (hidden in the .git directories). And wasn't CVS built on top
of RCS at the file level, too? CVS's problems were not RCS, they were in
how they used RCS and it's general overall features.

Kent

[Michael AppleWin Debugger Dev]

On Sunday, August 22, 2021 at 2:56:17 PM UTC-7, Kent Dickey wrote:

> The Apple II is archaic garbage, yet here we are emulating it.

Apples and Oranges comparison.

First, IF that was true we wouldn't be writing emulators for it.
Second, the design of the Apple 2 is pretty damn elegant.
Third, while the Apple 2 is primitive it STILL has better input latency then many modern systems.  Not bad for an "archaic system"! -- https://www.extremetech.com/computing/261148-modern-computers-struggle-match-input-latency-apple-iie
Fourth, there are STILL much software (such as many original games) on these old systems that are not available on a modern system.

Sure, from a performance POV old 8-bit computers are "archaic" but that doesn't make them garbage.  You are not going to be editing 4K video on an Apple 2.  The hardware can only do what the hardware can do.

A VCS has ONE job: To keep an accurate history of changes.

The design of RCS is archaic garbage because it doesn't meet the needs of modern developers.  There is a reason git and Perforce have become de facto standards amongst professionals -- the biggest being scalability.

Git makes common operations, such as branching and checkout, trivial.  RCS does not.

> Vi is archaic garbage, and I happily use it every day.

No.  It's design of using modes is far superior for many tasks -- which makes it trivial to repeat almost any command.  Something completely lost on modern text editors.  While Vi is getting a little long in the tooth Vim builds upon that good foundation.

> These arguments seem to mostly be insulting me.

Did you COMPLETELY miss the part where I said?

"If a 1st-gen VCS if works for you more power to you"

> You know, it's possible to write a version control system that
> worked exactly like Git in terms of interface and commands, and yet had RCS
> underneath it (hidden in the .git directories).

BWAHAHA.

1. You are not understanding the features of a distributed VCS let alone modern work-flow.
2. That would STILL be a garbage design AND implementation -- things such as performance, scalability, and size (of the repro.) matter.  For example, the Windows source code is 450 GB.  That is just to checkout "head".  Good LUCK trying to have RCS dealing with THAT.

Why is that a problem?  With RCS the older the checkout revision the longer the checkout takes since an increasing number of deltas need to be calculated.  In git this is O(1) since it is a matter of just updating a pointer.  While this time may not matter for small repos, for large repos this certainly does matter.  Why not just use a VCS that is designed better right from the start to handle scalability and won't run into performance issues until LONG down the road?

> And wasn't CVS built on top of RCS at the file level, too?

When you build upon a crap foundation you end with a shaky building -- which is all the more reason to avoid CVS as well.

> CVS's problems were not RCS, they were in
> how they used RCS and it's general overall features.

Doesn't change the fact that CVS is garbage too.  Did they _finally_ fix the inability to rename a file AND keep the revision history?  Can you rename a directory AND keep the revision history?  The CVS FAQ says this isn't possible.   This is idiotic.  The _contents_ of the file didn't change, only the meta-data did.  What the hell is the point of using a (broken) VCS if it can't even track basic changes???

The problem with CVS, and RCS, and why their design is fundamentally broken is that history is tracked on a per-file basis.  History of people using VCSs has shown that this is bad design.  Modern VCSs take a snapshot of the entire project which is the revision.

Linus (of Linux fame) has discussed to death some of the problems with CVS when he gave his git talk to google:

Tech Talk: Linus Torvalds on git
https://www.youtube.com/watch?v=4XpnKHJAok8

The world has moved on from crap like RCS and CVS for over 15+ years now.  Not just for 1 reason but for MANY reasons: Functionality, Performance, Security, Size, etc.

If you want to keep using an archaic VCS such as RCS then no one is going to stop you -- but you are selling yourself extremely short by not using a more modern VCS.  Almost no one is going to submit RCS patches to you.  With git it is _almost_ trivial to merge a PR.  I have submitted a few patches to various repros that I never would have unless git had made it easy:

* git clone foo
* edit file
* git add -p bar
* git commit "Fixed bar"
* git push
* Hit the PR button on GitHub

Compared to other VCSs git isn't THAT hard to learn.  It doesn't suffer from the same dumbs designs that others do.  As they say hindsight is 20/20 and git has benefitted very much from that.  Git, ironically, literally owes its existence to the closed source proprietary BitKeeper.

EVERY VCS sucks.  Knowing what they are good at, and what they are bad at, helps you pick and use tools that are easier, faster, etc.  Personally I think Vim sucks too.  I find it utterly retarded that in 2021 you STILL can't bind CAPS, Ctrl-1, Ctrl-Shift-1 because it is stuck in 1970's thinking.  However, I find Vim sucks _least_ compared to other editors. Ditto for git.  Git's lack of handling binary files without blowing up the repository is a major deal breaker with games.  For the longest time git couldn't handle large files so you have hacks/extensions like Git LFS (Large File Storage).  But for what git was designed to do it does a damn good job, far, far better then other VCSs.

If you feel insulted that I called RCS "archaic garbage" then you would know it is not just my opinion that RCS and CVS are hot garbage.  It would behoove you to learn WHY many professional developers have switched to git and Perforce.  (Having used Perforce I'm not a fan of it either -- it feels extremely clunky.)  I'd rather listen to the guy who not only made his own Operating System, has it running on 100% of the Top 500 supercomputers in the world, along with over 2 Billion mobile devices, AND wrote a better designed VCS that puts most of them to shame because, chances are, he is smarter than me then to some "nobody" that wrote a piece of software decades ago that almost NO ONE uses anymore because the broken design never got tossed out, nor did it kept evolving to deal with handling modern problems.  

People have used Vi to edit LARGE text files over dial-up.  THAT is a good design that stands up reasonably well today -- not archaic -- because it is performant.

RCS / CVS is like having a hammer.  You may think it is OK if all you need to do pound a few nails in but when you need to eventually drill holes, use a screwdriver for screws (go figure), etc. you will want to expand the proverbial toolbox with power tools that can not scale up but scale down as well.   RCS / CVS doesn't scale up hence why it is a complete joke amongst professional developers.

To summarize:

1. Use what you know.  Take the blue pill and remain happy in your ignorance.
2. Or take the red pill and don't be surprised when people offer better alternatives based on years of experience of having attempted to solve the same problems year in, year out.

We now return to your favorite emulator discussion ...

m.

[Michael J. Mahon]

Michael AppleWin Debugger Dev <michael....@gmail.com> wrote:

Michael, I understand that you are a happy git user—great. But surely you
can understand how someone developing a personal project could be happy
doing things another way that works well for them.

This reminds me of the “my editor is better than your editor” arguments,
which ultimately resolve to “there’s no disputing tastes”.

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com

[Michael AppleWin Debugger Dev]

On Sunday, August 22, 2021 at 9:16:02 PM UTC-7, Michael J. Mahon wrote:
> But surely you
> can understand how someone developing a personal project could be happy
> doing things another way that works well for them.

Which is why I've stated TWICE now:

"If a 1st-gen VCS if works for you more power to you"

and

"1. Use what you know. "

Not sure how many more times I need to repeat myself.

m.

[Jeff Blakeney]

Michael, you keep saying that one of the best reasons to use the things
you are promoting are because they have been adopted by many modern,
professional programmers. Just to let you know, I gave up on doing
programming for a living because the entire industry went in, what I
consider to be, really stupid directions.

The popular programming languages I find are designed to create job
security by purposely making it difficult to understand the code. This
has the side effect of making it difficult, at least for me, to be able
to create code in that language. Also, I'm constantly baffled by the
size of many modern applications so the modern languages seem to add a
lot of bloat to the executable.

Windows 10 does SO many stupid things I absolutely dread when people ask
me to help them with a problem with their computer. I'm sure the source
for it is 450 GB because it isn't just an operating system. It is also
a collection of programs that I use less than 1% of and I'm sure it
makes up well over 50% of the Windows install on my computer.

The whole development cycle model nowadays is also annoying. Let's
write a program, maybe do some basic testing, release it, then keep
putting out updates every week to fix all the bugs that are found by the
public using it.

My brother is still programming for a living and he keeps telling me
about his frustrations with dealing with some of the tools that he has
to use. This is partly because he is involved in larger projects with
multiple programmers and some group of people decide how they are going
to do things and invariably pick poor options that cause him to have to
do extra work.

So, just because something is in wide spread use doesn't mean that it is
good or is the only way things should be done. Many modern programmers
are using certain tools simply because it is mandated by their employers
and the decisions to use those specific tools was made by others who may
not know anything about programming.

We get it, you like Git and you promoted it but after someone tells you
that they aren't interested in using it, you really shouldn't keep
trying to push it on them.

[Michael AppleWin Debugger Dev]

On Monday, August 23, 2021 at 6:45:07 AM UTC-7, Jeff Blakeney wrote:
> Michael, you keep saying that one of the best reasons to use the things
> you are promoting are because they have been adopted by many modern,
> professional programmers. Just to let you know, I gave up on doing
> programming for a living because the entire industry went in, what I
> consider to be, really stupid directions.

Yes, the industry is littered with many bad examples.

> The popular programming languages I find are designed to create job
> security by purposely making it difficult to understand the code. This
> has the side effect of making it difficult, at least for me, to be able
> to create code in that language.

No argument here. Too many programmers, especially the younger ones, don't understand KISS. Just because you CAN do something doesn't mean you can. They love to over-engineer the simplest of problems. One of the "best" examples of the Boost's CRC clusterfuck. Over 2,000 LOC when around 25 lines would do the same job.

I've worked on a C++ compiler. We have an old joke:

There are 2 problems with C++

1. It's design
2. It's implementation

> Also, I'm constantly baffled by the
> size of many modern applications so the modern languages seem to add a
> lot of bloat to the executable.

Yes. People include a library for one function, which in turn requires another 2 libs which in turn requires a few more libraries.

At my last job we were using jQuery. We did an "audit" of stuff we were _actually_ using. We had originally been using it's animation system but we had our own (since jQuery doesn't provide any WebGL animation). We also were using another function that I ended up re-writing. We ended up saving over 100K of network traffic. Our entire application was smaller then the video library we included.

> Windows 10 does SO many stupid things I absolutely dread when people ask
> me to help them with a problem with their computer.

For the longest time I flat outright told friends and family: No, I will NOT support Windows 10.

> I'm sure the source
> for it is 450 GB because it isn't just an operating system. It is also
> a collection of programs that I use less than 1% of and I'm sure it
> makes up well over 50% of the Windows install on my computer.

Yes, that's because Microsoft has never really understood the Unix philosophy. Do one thing.

> The whole development cycle model nowadays is also annoying. Let's
> write a program, maybe do some basic testing, release it, then keep
> putting out updates every week to fix all the bugs that are found by the
> public using it.

Yes. The levels of abstraction for modern programming is crazy.

Which is why I, ironically, still program in 6502 assembly, to stay sane. One person CAN literally understand the entire system.

> My brother is still programming for a living and he keeps telling me
> about his frustrations with dealing with some of the tools that he has
> to use. This is partly because he is involved in larger projects with
> multiple programmers and some group of people decide how they are going
> to do things and invariably pick poor options that cause him to have to
> do extra work.

I've always reminded of Murphy's Computer Law:

MESKIMEN'S LAW
There's never time to do it right, but always time to do it over.

Yes, it isn't accident that the industry is littered with crap languages, PHP, Python, Java, Javascript, crap tools, CMake, etc, and LOVES to reinvent technology. The web was reinvented 3 times.

> So, just because something is in wide spread use doesn't mean that it is
> good or is the only way things should be done. Many modern programmers
> are using certain tools simply because it is mandated by their employers
> and the decisions to use those specific tools was made by others who may
> not know anything about programming.

Correct. I usually use this example:

Just because McDonalds serves BILLIONS of food doesn't mean they are serving gourmet food. Quantity != Quality.

The difference is that git was actually designed to solve modern problems:

* Authenticity
* Performance
* Scalability
* Distributed Nature

None of the first gen VCS even come close to making a dent in those.

> We get it, you like Git and you promoted it but after someone tells you
> that they aren't interested in using it, you really shouldn't keep
> trying to push it on them.

If a person expects their program stick around it means they will need to accept patches which mean using modern tools which GREATLY simplify this.

I've used my fair share of VCSs over the years. Most of them are garbage. I'm not going to make excuses why someone's archaic VCS is a piece of shit.

m.

[Michael AppleWin Debugger Dev]

On Sunday, August 22, 2021 at 1:06:49 PM UTC-7, Nicola wrote:
> I find Fossil (https://fossil-scm.org/) better designed than Git, and

> ...

> In any case, you keep control
> over *all* of your data, including tickets and discussions. How do you
> move away from GitHub or GitLab without losing such information?

Moving out of GitHub is an issue I've wondered about. Always good to hear about replacements. Thanks for the link Nicola!

> Whereas in Git you can easily shoot yourself, e.g.,
> with something like `git reset --hard`.

That is true. That's one of [potential] downsides with git -- it gives you a LOT of power. Thankfully most operations can be undone if you immediately stop and lookup how to undo the last operation.

For "dangerous" operations is always a good idea to test them out on either a small toy project, or a clone, of the repository.

You wouldn't use a power saw/sander/etc. on your _good_ wood without first testing it out on _scrap_ lumber, right? :-)

m.

[Michael J. Mahon]

Michael AppleWin Debugger Dev <michael....@gmail.com> wrote:

> I've always reminded of Murphy's Computer Law:
>
> MESKIMEN'S LAW
> There's never time to do it right, but always time to do it over.

Or one of “Mahon’s Laws”:

“Quick and dirty” is never quick but always dirty.

[Michael AppleWin Debugger Dev]

On Monday, August 23, 2021 at 9:12:00 AM UTC-7, Michael J. Mahon wrote:
> Or one of “Mahon’s Laws”:
>
> “Quick and dirty” is never quick but always dirty.

LOL. So painful but true.

I'm added that to my quotes file (with proper attribution of course.)

m.