Are GSport and GSPlus dead?

Post by Brandon Taylor
My question is kind of a two-parter. I've looked at the GitHub repository pages for GSport and GSPlus, two forks of KEGS. I've noticed that the last updates for both of these projects date back to 2020 and 2019, respectively. So my question is, are these projects dead?

GSport is at something of a crossroads due to Apple's incessant
switching of display technologies. Navigating a code path that works
for older machines and newer machines alike is (and always has been)
difficult. And Apple makes it so very much harder. If you still want
to run on OSX 10.3 (hey, you're emulating an Apple II from 1986... I'm
not here to judge) then this repo is the only way to go.

Anyway, enough whining. There's a branch in GSport that includes
GSPlus' video updates in case we wanted to go that route, but...

Post by Brandon Taylor
And now, Kent Dickey, if these projects ARE dead, do you think you could fork some of the source code from them and integrate it into future versions of KEGS? I for one would love to see you add emulation for Epson LQ and ImageWriter printers.

I for one would love to see this too - and was what I approached Kent
with before I forked and started GSport. I'd rather not fracture repos.
I'll be first to post PRs if that ever happens.

Brandon Taylor

2022-05-07 01:46:15 UTC

GSport is at something of a crossroads due to Apple's incessant
switching of display technologies. Navigating a code path that works
for older machines and newer machines alike is (and always has been)
difficult. And Apple makes it so very much harder. If you still want
to run on OSX 10.3 (hey, you're emulating an Apple II from 1986... I'm
not here to judge) then this repo is the only way to go.
Anyway, enough whining. There's a branch in GSport that includes
GSPlus' video updates in case we wanted to go that route, but...

I for one would love to see this too - and was what I approached Kent
with before I forked and started GSport. I'd rather not fracture repos.
I'll be first to post PRs if that ever happens.

Okay. So, Kent, would you be open to posting KEGS to GitHub so you and David can compare notes, as it were? Not that I'm asking you to ditch SourceForge or anything like that, but... if not GitHub, then where?

mmphosis

2022-05-07 19:17:34 UTC

Post by Brandon Taylor
Okay. So, Kent, would you be open to posting KEGS to GitHub so you and
David can compare notes, as it were? Not that I'm asking you to ditch
SourceForge or anything like that, but... if not GitHub, then where?

Compare away, it's here:

http://kegs.sourceforge.net/kegs.1.16.tar.gz

Why the attachment to the walled garden? It will soon require tfa
https://www.theverge.com/2022/5/4/23056799/github-contributors-2fa-two-factor-authentication-2023
and who knows what else Embrace, extend, and extinguish. sourceforge has
made missteps as well
https://en.wikipedia.org/wiki/SourceForge#Controversies

As for where? There are too many alternative to list. What about a
self-hosted mirror?

https://en.wikipedia.org/wiki/List_of_version-control_software

https://en.wikipedia.org/wiki/Comparison_of_source-code-hosting_facilities

Brandon Taylor

2022-05-08 00:35:26 UTC

Post by mmphosis

http://kegs.sourceforge.net/kegs.1.16.tar.gz
Why the attachment to the walled garden? It will soon require tfa
https://www.theverge.com/2022/5/4/23056799/github-contributors-2fa-two-factor-authentication-2023
and who knows what else Embrace, extend, and extinguish. sourceforge has
made missteps as well
https://en.wikipedia.org/wiki/SourceForge#Controversies
As for where? There are too many alternative to list. What about a
self-hosted mirror?
https://en.wikipedia.org/wiki/List_of_version-control_software
https://en.wikipedia.org/wiki/Comparison_of_source-code-hosting_facilities

After careful consideration of both source codes, I have determined that KEGS and its forks (GSport and GSPlus) have taken radically different directions; and thus, to attempt to merge the source codes of both of these projects would be close to impossible. However, by looking at just the 'config.c' files of both projects, I might be able to determine just exactly where the references to David's printer files should go in Kent's source code. Right now, I'm too lazy to do it, but I'm just saying, by picking and choosing what features we want added to KEGS, we might be able to compile our own custom versions of Kent's emulator.

David Schmidt

2022-05-09 17:15:28 UTC

Post by mmphosis

I would be happy to PR in the features I made into KEGS, as it would be
"easy" to rebase on Kent's most recent code. That's the only thing that
would make sense now - to merge in on a feature-by-feature basis. And
I'm sure the GSport contributors would be equally interested in getting
their respective features back on the mothership as well. When/if KEGS
gets into a collaborative space, that work can commence.

Another option is to do the same thing in GSport over again: rebase all
GSport changes on KEGS 1.16 and call that GSport++. But I'd really
rather participate in KEGS itself than a fork of it.

Brandon Taylor

2022-05-10 02:05:38 UTC

Post by mmphosis

I would be happy to PR in the features I made into KEGS, as it would be
"easy" to rebase on Kent's most recent code. That's the only thing that
would make sense now - to merge in on a feature-by-feature basis. And
I'm sure the GSport contributors would be equally interested in getting
their respective features back on the mothership as well. When/if KEGS
gets into a collaborative space, that work can commence.
Another option is to do the same thing in GSport over again: rebase all
GSport changes on KEGS 1.16 and call that GSport++. But I'd really
rather participate in KEGS itself than a fork of it.

Well, no matter which way you and Kent (and digarok too) go, I'm sure it will be a noble cause. Meanwhile, as for me, who isn't really much of a developer, I'm just going to sit back and enjoy all that these respective emulators have to offer.

Matthew Hellinger

2022-05-22 04:36:13 UTC

OP, I think the following repository is the most up-to-date fork of GSPlus that includes informally proposed and non-merged fixes/tweaks: https://github.com/applemu/gsplus

My own diff analysis of GS+ and GSport suggest that GS+ wraps in all the functional changes introduced by GSport and more. It's awesome to see some updates come out for KEGS.

I think all of these emulators work reasonably well, the only major new consideration is the introduction of 4K+ displays and I don't believe any of the flavors support window scaling.

The work being done for non-Windows AppleWin (https://github.com/audetto/applewin) is using Imgui (SDL2), which provides a great cross-platform UI solution. Getting GS+ to run under (Cimgui) isn't all that hard. Imgui is quickly becoming a UI of choice by emulators (including https://github.com/jmthompson/xgs) and the advantage of standardizing the graphics engine is that the primary focus can go into the emulator itself and not a particular operating system's windowing system eccentricities.

Post by Brandon Taylor
After careful consideration of both source codes, I have determined that KEGS and its forks (GSport and GSPlus) have taken radically different directions; and thus, to attempt to merge the source codes of both of these projects would be close to impossible. However, by looking at just the 'config.c' files of both projects, I might be able to determine just exactly where the references to David's printer files should go in Kent's source code. Right now, I'm too lazy to do it, but I'm just saying, by picking and choosing what features we want added to KEGS, we might be able to compile our own custom versions of Kent's emulator.

Kent Dickey

2022-06-02 21:04:29 UTC

Post by Brandon Taylor
My question is kind of a two-parter. I've looked at the GitHub

repository pages for GSport and GSPlus, two forks of KEGS. I've noticed
that the last updates for both of these projects date back to 2020 and
2019, respectively. So my question is, are these projects dead?

Post by David Schmidt
GSport is at something of a crossroads due to Apple's incessant
switching of display technologies. Navigating a code path that works
for older machines and newer machines alike is (and always has been)
difficult. And Apple makes it so very much harder. If you still want
to run on OSX 10.3 (hey, you're emulating an Apple II from 1986... I'm
not here to judge) then this repo is the only way to go.
Anyway, enough whining. There's a branch in GSport that includes
GSPlus' video updates in case we wanted to go that route, but...

Post by Brandon Taylor
And now, Kent Dickey, if these projects ARE dead, do you think you

could fork some of the source code from them and integrate it into
future versions of KEGS? I for one would love to see you add emulation
for Epson LQ and ImageWriter printers.

Post by David Schmidt
I for one would love to see this too - and was what I approached Kent
with before I forked and started GSport. I'd rather not fracture repos.
I'll be first to post PRs if that ever happens.

Okay. So, Kent, would you be open to posting KEGS to GitHub so you and
David can compare notes, as it were? Not that I'm asking you to ditch
SourceForge or anything like that, but... if not GitHub, then where?

I am not planning to move to GitHub for KEGS revision control. I've managed
to avoid using Git in any serious way yet, and I see no reason to do so now.
Git has created a whole slew of ridiculous jargon ("pull request") and I
dislike it for lots of reasons. I don't want to discuss this since I am
tired of being spoken down to like I'm an idiot for not using Git.
And if I put KEGS on github, then I'll have to deal with submissions through
git, and I don't want that.

As for accepting patches, I will generally accept public domain patches. I
may accept GPL-licensed patches, but it needs to be "isolated". I've
managed to make some money on KEGS, and is why I kicked out all
contributions 15 years ago. Adding back in GPL patches just makes more
work for me. If you want imagewriter.c to be GPL, but the other parts of
the patch to other files in KEGS to be public domain, then that would be
fine with me.

Just email the changed files to me--but really, before doing a lot of
work, email me and describe what you want to do, how it will work, etc.
I may decide not to accept it at that point, and can save you a lot of
time. If you require KEGS to run as root or other big user experience
changes, then it's less likely to be accepted. I'll be honest--I've not
looked at GSplus or GSport much, so I've not really looked into how the
printer stuff works.

And I'm crazy busy lately, so don't expect quick replies.

Kent

fadden

2022-06-03 15:42:11 UTC

As for accepting patches, I will generally accept public domain patches. I
may accept GPL-licensed patches, but it needs to be "isolated".

I have spent a depressing amount of time working around the GPL's viral nature. In CiderPress I made sure that the two things that used it (HFS filesystem and FDI disk images) were optional, so that I could evict them if they became an issue. (At one point I pinged the libhfs author about switching to LGPL; no reply.)

One of the things I appreciate about the Apache 2 license is this bit:

5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. [...]

Unless somebody goes out of their way to indicate a different license, the code becomes subject to Apache terms. This interacts nicely with a formal change submission mechanism, because it provides a record of where the code came from. If somebody doesn't actually have the rights to the code they're submitting, there's a server-side record of the fact that they submitted it. If the code is e-mailed to me and I submit it, that trail is not part of the repository, and it's harder to fix the blame if somebody submits non-free code.

Kent Dickey

2022-06-13 04:20:45 UTC

As for accepting patches, I will generally accept public domain patches. I
may accept GPL-licensed patches, but it needs to be "isolated".

I have spent a depressing amount of time working around the GPL's viral
nature. In CiderPress I made sure that the two things that used it (HFS
filesystem and FDI disk images) were optional, so that I could evict
them if they became an issue. (At one point I pinged the libhfs author
about switching to LGPL; no reply.)
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work by
You to the Licensor shall be under the terms and conditions of this
License, without any additional terms or conditions. [...]
Unless somebody goes out of their way to indicate a different license,
the code becomes subject to Apache terms. This interacts nicely with a
formal change submission mechanism, because it provides a record of
where the code came from. If somebody doesn't actually have the rights
to the code they're submitting, there's a server-side record of the fact
that they submitted it. If the code is e-mailed to me and I submit it,
that trail is not part of the repository, and it's harder to fix the
blame if somebody submits non-free code.

But...I also don't want other people commercializing and selling KEGS.
Using Apache doesn't solve that problem. Really, kicking GPL code out
of KEGS was almost no work for me, but it made a bunch of people really
angry. Some GPL code has crept back in, but I'm not sure anyone will
want to license it anymore either.

And, I just implement stuff my own way, even stuff that's licensed pretty
freely, because KEGS is my hobby, not my job. So the .zip algorithm in KEGS
is written by me, not a library. But I learned how .zip works which I
wouldn't have done if I just used libzip.

Kent

fadden

2022-06-13 15:31:39 UTC

Post by Kent Dickey
But...I also don't want other people commercializing and selling KEGS.

Why not?

Is it better to have someone ignore your code and rewrite it? Seems like that doesn't help anybody.

If somebody wants to charge money for 6502bench or CiderPress, they can. I think anybody who pays for it is a fool, but it's not my job to protect other people's wallets. And if the seller took the time to improve it significantly, they're entitled to be paid.

Post by Kent Dickey
Using Apache doesn't solve that problem.

Neither does GPL. I can sell your emulator if I want. I just have to give away any modifications I make that are linked into the program. If KEGS is a component of a larger product, and can be isolated across a process boundary, then giving away modifications may not be a limiting factor. Selling it simply as a stand-alone emulator likely wouldn't make sense though, since a free equivalent would be available.

Post by Kent Dickey
And, I just implement stuff my own way, even stuff that's licensed pretty
freely, because KEGS is my hobby, not my job. So the .zip algorithm in KEGS
is written by me, not a library. But I learned how .zip works which I
wouldn't have done if I just used libzip.

Interesting choice for an example... I've written the same damn zipfile access code about 3x now. The code I wrote for CiderPress wound up in modified form in Android a couple of times (the APK packaging code, the zipalign tool, tweaked heavily for java.util.Zip, ...). It's interesting the first time around, but after that it's nice to have a fully debugged library.

I am Rob

2022-06-13 18:41:59 UTC

Post by Kent Dickey
But...I also don't want other people commercializing and selling KEGS.

Why not?
Is it better to have someone ignore your code and rewrite it? Seems like that doesn't help anybody.
If somebody wants to charge money for 6502bench or CiderPress, they can. I think anybody who pays for it is a fool, but it's not my job to protect other people's wallets. And if the seller took the time to improve it significantly, they're entitled to be paid.

Another way of looking at it is, we all pretty much learned bits and pieces of code from someone else. Even if we re-write the code to make it our own, does that really make it ours. Or is it just the idea that is not ours. And if everyone lived in fear of someone else profiting off of their own code, then code or programs would never get written.

I think nowadays, no one wants to pay for software as there is so much free programs and games already out there. But if anyone does charge something, it is usually to cover the costs of hardware. Cd's, DVD's, website creation, server rental.

Post by fadden
And, I just implement stuff my own way, even stuff that's licensed pretty
freely, because KEGS is my hobby, not my job.

I am still hopeful that VGA described in another thread will eventually be on your todo list.

Brandon Taylor

2022-06-13 23:14:58 UTC

Post by Kent Dickey
But...I also don't want other people commercializing and selling KEGS.

Why not?
Is it better to have someone ignore your code and rewrite it? Seems like that doesn't help anybody.
If somebody wants to charge money for 6502bench or CiderPress, they can. I think anybody who pays for it is a fool, but it's not my job to protect other people's wallets. And if the seller took the time to improve it significantly, they're entitled to be paid.

Another way of looking at it is, we all pretty much learned bits and pieces of code from someone else. Even if we re-write the code to make it our own, does that really make it ours. Or is it just the idea that is not ours. And if everyone lived in fear of someone else profiting off of their own code, then code or programs would never get written.
I think nowadays, no one wants to pay for software as there is so much free programs and games already out there. But if anyone does charge something, it is usually to cover the costs of hardware. Cd's, DVD's, website creation, server rental.

Post by fadden
And, I just implement stuff my own way, even stuff that's licensed pretty
freely, because KEGS is my hobby, not my job.

I am still hopeful that VGA described in another thread will eventually be on your todo list.

Gentlemen, please. It was not my intention to start a platform battle between SourceForge and GitHub.

I can certainly understand, Kent, where you're coming from, and I suppose another reason you have to avoid GitHub like the plague is because it is a Microsoft service, and your code would no longer be 100 percent yours, but would fall under Microsoft's scrutiny. (That being said, in a way, it already has fallen under Microsoft's scrutiny in the form of both GSport and GSPlus.)

The decision you've made to never use GitHub is one I can totally respect -- all I was doing was throwing the suggestion out there.

I admit, however, that I was quite possibly wrong to do so, as I seem to have unwittingly sparked an unholy argument.

Kent Dickey

2022-06-26 21:49:07 UTC

Post by Kent Dickey
But...I also don't want other people commercializing and selling KEGS.

Why not?
Is it better to have someone ignore your code and rewrite it? Seems
like that doesn't help anybody.
If somebody wants to charge money for 6502bench or CiderPress, they can.
I think anybody who pays for it is a fool, but it's not my job to
protect other people's wallets. And if the seller took the time to
improve it significantly, they're entitled to be paid.

I guess I should say: I don't want to see someone else steal my work and
make money at it and claim it as their own.

Post by Kent Dickey
Using Apache doesn't solve that problem.

Neither does GPL. I can sell your emulator if I want. I just have to
give away any modifications I make that are linked into the program. If
KEGS is a component of a larger product, and can be isolated across a
process boundary, then giving away modifications may not be a limiting
factor. Selling it simply as a stand-alone emulator likely wouldn't
make sense though, since a free equivalent would be available.

GPL isn't exactly what I'm looking for, but since GPL requires the
release of source code, if someone did sell KEGS, I could always get
access to their changes. If it's priced so high that I wouldn't buy it,
probably no one else is either. And GPL effectively requires credit.

Interesting choice for an example... I've written the same damn zipfile
access code about 3x now. The code I wrote for CiderPress wound up in
modified form in Android a couple of times (the APK packaging code, the
zipalign tool, tweaked heavily for java.util.Zip, ...). It's
interesting the first time around, but after that it's nice to have a
fully debugged library.

Fully debugged library. That's a good one.

Kent

fadden

2022-06-27 15:29:41 UTC

Post by Kent Dickey
I guess I should say: I don't want to see someone else steal my work and
make money at it and claim it as their own.

FWIW, Apache 2 does require credit, both in terms of carrying a "NOTICE" forward and marking files that have been changed as such (see part 4 in the license). It's less specific than GPL, but it's there.

People might not be able to steal your code, but it seems to me that the hard part of writing an emulator is two things: developing clever algorithms to make stuff go fast, and figuring out all the weird undocumented behavior and edge cases. Neither of those is covered by copyright. So the question is: what is the work that you don't want stolen? Your implementation, or your ideas and research? (I suspect this is why a number of other emulators aren't even available as source code.)

My oversimplified view of open source is essentially this: use GPL if you want other people to collaborate on your project, use Apache 2 / MIT / BSD if you want other people to use your code in their own projects. If you're only publishing the code so that other people can compile it, don't use an open-source license... that way, if somebody else does sell your code, you can throw the full weight of copyright law at them.

Kent Dickey

2022-06-27 17:57:56 UTC

Post by Kent Dickey
I guess I should say: I don't want to see someone else steal my work and
make money at it and claim it as their own.

FWIW, Apache 2 does require credit, both in terms of carrying a "NOTICE"
forward and marking files that have been changed as such (see part 4 in
the license). It's less specific than GPL, but it's there.
People might not be able to steal your code, but it seems to me that the
hard part of writing an emulator is two things: developing clever
algorithms to make stuff go fast, and figuring out all the weird
undocumented behavior and edge cases. Neither of those is covered by
copyright. So the question is: what is the work that you don't want
stolen? Your implementation, or your ideas and research? (I suspect
this is why a number of other emulators aren't even available as source
code.)
My oversimplified view of open source is essentially this: use GPL if
you want other people to collaborate on your project, use Apache 2 / MIT
/ BSD if you want other people to use your code in their own projects.
If you're only publishing the code so that other people can compile it,
don't use an open-source license... that way, if somebody else does sell
your code, you can throw the full weight of copyright law at them.

I don't want someone to take KEGS, change a few lines (to remove my
name, change the name to Apple2GSK00lEmulator), and put games for sale
on someplace for $5 each and pass it off as theirs. I think there is a
market here (although not large, but enough to make some money at), and I
don't want to easily enable slimy people to take it. Meanwhile, if
someone puts a lot of effort into improving KEGS, them selling it
bothers me a lot less, but I think it would be a shame if those changes
weren't also made public. The GPLv3 seems to reasonably cover both of
these cases (although indirectly for the first one--just because most
types of people who would pass off the code as theirs would violate the
GPL because they just don't care, not that there isn't a way for them to
do what I just said without violating the GPL). So GPLv3 seems to give me
what I want.

As for collaboration: 80%+ of people are great to work with. I don't
like dealing with the bad 10%. You have to pay me to deal with those
people. I don't have a solution for this, so I just make it harder to
contribute to KEGS.

I'm fine with people using the research of KEGS to make emulators--but
as of now, KEGS is obsoleted by MAME which is likely more accurate at
almost everything. KEGS code is a little easier to understand, maybe.

You mention a non-open-source license that lets people compile code:
What license would this be? By picking GPL, I get people basically
understanding the license right away without me having to explain it,
and it potentially gives me allies to assist in enforcing it since there
are GPL fans. If I create my own license, no one will help enforce it.

Kent

fadden

2022-06-27 23:46:47 UTC

Post by Kent Dickey
What license would this be?

"Copyright Kent Dickey, All Rights Reserved." The act of posting it gives people the right to read it for their own personal use, but not to distribute it or create derivative works. I believe feeding it into a compiler is fair use for source code, so long as they don't distribute the output. (Note: I Am Not A Lawyer.)

In any event, GPL sounds like the right choice for KEGS.

Brandon Taylor

2022-06-04 15:19:41 UTC

Post by Brandon Taylor
My question is kind of a two-parter. I've looked at the GitHub

Post by Brandon Taylor
And now, Kent Dickey, if these projects ARE dead, do you think you

could fork some of the source code from them and integrate it into
future versions of KEGS? I for one would love to see you add emulation
for Epson LQ and ImageWriter printers.

Okay. So, Kent, would you be open to posting KEGS to GitHub so you and
David can compare notes, as it were? Not that I'm asking you to ditch
SourceForge or anything like that, but... if not GitHub, then where?

I am not planning to move to GitHub for KEGS revision control. I've managed
to avoid using Git in any serious way yet, and I see no reason to do so now.
Git has created a whole slew of ridiculous jargon ("pull request") and I
dislike it for lots of reasons. I don't want to discuss this since I am
tired of being spoken down to like I'm an idiot for not using Git.
And if I put KEGS on github, then I'll have to deal with submissions through
git, and I don't want that.
As for accepting patches, I will generally accept public domain patches. I
may accept GPL-licensed patches, but it needs to be "isolated". I've
managed to make some money on KEGS, and is why I kicked out all
contributions 15 years ago. Adding back in GPL patches just makes more
work for me. If you want imagewriter.c to be GPL, but the other parts of
the patch to other files in KEGS to be public domain, then that would be
fine with me.
Just email the changed files to me--but really, before doing a lot of
work, email me and describe what you want to do, how it will work, etc.
I may decide not to accept it at that point, and can save you a lot of
time. If you require KEGS to run as root or other big user experience
changes, then it's less likely to be accepted. I'll be honest--I've not
looked at GSplus or GSport much, so I've not really looked into how the
printer stuff works.
And I'm crazy busy lately, so don't expect quick replies.
Kent

Kent -- I must apologize if it sounded as if we were talking down to you. As far as I know, no one here was intentionally trying to call you an idiot. Or, if someone did, we'll do what we can to take them to task.

Oliver Schmidt

2022-06-05 18:05:11 UTC

Hi Kent,

Post by Kent Dickey

I personally think that it's a bad thing to call somebody an idiot for
any reason whatsoever. So, if someone did so to you for not using
GitHub, than I detest that!

But, I can't see that happening above: "... would you be open ..." and
"... if not GitHub, then where?" seem rather open-minded to me.

From my POV, GitHub/GitLab are currently the by far most popular
platforms for collaboration of project owners with project
contributors (in contrast to project members).

It seems to me that KeGS falls into that category (owner +
contributors) so it comes as no surprise that you are asked about
GitHub.

I personally don't see a reason to be upset about what was written in
this thread.

Looking forward, You're not going to use GitHub for what ever reason -
and you explained how contribute instead. It would be great so see
just that happen!

Just, my two cents

Michael AppleWin Debugger Dev

2022-06-06 16:03:48 UTC

Post by Kent Dickey
Git has created a whole slew of ridiculous jargon

Translation: Old man stuck in his ways makes excuses for why they don't want to learn how modern platforms *streamline* project management. /s

A SCM is *not* just about code but about ways to communicate and manage it such as handling contributions, forking, merge conflicts, CI/CD, feedback, bugs, issues, documentation, branches, tags, releases, license management, etc.

You know, all the META project stuff that keeps popping up from project to project. As the Mythical Man-Month describes the overhead of communication on a team is an N^2 problem. HOW you manage this is more important then the code.

git has "new" terminology because it solves problems other SCM don't -- or if they do, they do such a piss-poor job that you would be short-sighted to use inferior tools making your life much hardier then it needs to be. GitHub makes this power *accessible.* Show me a SCM that _doesn't_ have special syntax for its operations? Now show me how difficult it is to do common operations? CVS died because it is shit. SVN stayed around because it fixed most of the problems with CVS. It is dying because it didn't evolve to solve problems of modern software development. Perforce has persisted because of a business case but even that is becoming niche. AlienBrain died due to pricing. The history of SCMs is littered with dead products that didn't evolve to meet new needs.

Hell, even a SCM is a difficult concept for some people and they whine about having to "check out" and "check in" a file. Once you start going down the road of a content authoring system with multiple authors you NEED a system to manage the complexity. "New" terminology is needed to deal with new issues. i.e. Two people both change the 1st sentence of the 2nd paragraph on page 3. How do you determine who is "correct"? This "merge conflict" needs to be resolved somehow? How do you manage "infinite" branching where you move along all the versions? etc.

Regardless of whatever SCM system you have (or don't have) you need to deal with the same problems of management and communication with team members.

IMO git blows (almost) every other SCM out of the water with features, performance, security, and stability. There is a learning curve with any system but one of the nice things is that due to its popularity git has TONs of guides. Hell, even SO (Stack Overflow) pretty much has an answer for whatever git / github question you have due to your edge case.

Even for solo projects I use git and github exclusively because I can spend less time dealing with the overhead of management and can focus more on the code itself.

For AppleWin we switched from BerliOS to GitHub years ago because we were forced to due to BerliOS shutting down. After looking at our alternatives we migrated from svn to git. It was one of the best decisions ever made. GitHub has made our job of managing the code MUCH, MUCH, MUCH easier -- not just for our own code but for submissions from others. GitHub has literally made merging PRs (Pull Requests) pretty much idiot proof -- especially with the ability to Review PR, Request Changes, leave comments, and Merge UI. There is a reason MANY projects use GitHub.

Managing a "local" repo is trivial to start with 3 commands:

git init
git add foo
git commit -m "Initial implementation"

To convert this into a "remote" repo that others can contribute to only two more steps are needed. The REAL power of git is that GitHub makes it **EASY to coordinate work with others.** GitHub lowers the barriers [to make it trivial to accept patches.]

Whining that "git is too hard to learn" is just stubborn laziness not wanting to learn the pros/cons of git and the entire ecosystem of what GitHub provides.

At work we use BitBucket and are migrating to GitHub later this year because most developers agree that GitHub is more in tune with what we developers actually expect, want, and need out of an SCM.

Oblg. car analogy: Not learning git in 2020+ is like using a horse and buggy whining that cars are moving 10x your speed because you don't want to learn how to re-fuel these fancy schmancy "horseless carriages".

Oblg. woodworking analogy: There is a time and place for hand tools but the rest of the world has moved onto power tools such as git and GitHub to handle the 99% boring management stuff.

Any project will die without community involvement. GitHub makes it trivial keep it alive -- especially by having a "Fork" button.

You're probably getting flack because your are _constantly_ making excuses for not learning modern SCM tools and then whine that git makes up "jargon" -- all because you are too lazy to understand the problem and context that git is (attempting to) solve. With power comes complexity. With it also comes the ability to streamline different problems.

The "old" Linus would probably say: Anyone not using git is probably a git. /s =P

The "new" Linux would probably say: You can do SCM the hard way or the easy way. Git is easy once you learn how. True, there is a learning curve but what professional doesn't learn how to use their tools???

As gamers say: git gud =P

m.

mmphosis

2022-06-06 21:25:46 UTC

Good to hear from you Michael.

<rant>There are redundant snapshots on github, but Linux does not use
github. I watched the wwdc keynote today hosted by some old men. The new
buzzword is "collaboration." All of this sales pitch is to try to sell
vendor lock-in. "Popularity" is not a reason. And "pretty much idiot proof"
is insulting - like reading "Computers for Dummies" when what we really want
is computers for smart people. You are correct about Laziness, and don't
forget Impatience, and Hubris. If the maintainers of the forks want to
"Manage" complexity - you can fill your boots. We may have moved on from
horse and buggy, but I am still waiting for the electric car that came out
in the 1800s. The more things change, the more they stay the same. If
version control systems were so great, I'd still be using DEC command line.
Hey it's 2022, and if I want something to work I need to type a cryptic
command on a command line. If I do move to SCM, now I have two
problems.</rant>

Enough ranting. More coding. Cheers!

https://github.com/mmphosis

Jeff Blakeney

2022-06-07 18:09:10 UTC

Post by Michael AppleWin Debugger Dev
"New" terminology is needed to deal with new issues. i.e. Two
people both change the 1st sentence of the 2nd paragraph on page 3.
How do you determine who is "correct"? This "merge conflict" needs
to be resolved somehow?

I find it funny that you describe the need for "new" terminology without
using *any* new terminology?

Also, even GitHub can't determine who is correct automatically. All it
can do is flag it as a problem for a person to deal with.

Post by Michael AppleWin Debugger Dev
Translation: Old man stuck in his ways makes excuses for why they
don't want to learn how modern platforms *streamline* project
management.

[snip]

Post by Michael AppleWin Debugger Dev
Whining that "git is too hard to learn" is just stubborn laziness not
wanting to learn the pros/cons of git and the entire ecosystem of
what GitHub provides.

[snip]

Perhaps *you* should stop whining because someone else doesn't agree
with your opinion? Kent doesn't like or want to use GitHub and that is
his opinion and choice. Trying to insult him for it makes you look
petty and mean (there was a word I could have used here but I thought
I'd keep it polite). You could have just posted what you think are the
benefits of it instead of talking down to those who don't agree with you.

I too don't see the need for such a system as I have never been involved
in large, collaborative programming projects. 1999 to 2001 or so I used
to work with my brother on billing software for the electricity market
in the province where I live. We tried using SVN for a while but it
really didn't add anything for us other than maybe adding a little extra
work for dealing with the SVN. Mind you, this is only a two person
project so my brother would tell me what to work on and he would work on
something else. We had a standardized system of dated comments to
document the modifications we made to each piece of code so we knew when
and what was changed.

I gave on on programming for a career as I really didn't like all the
extra overhead people kept adding (I need this one function so I'll add
a multi-megabyte library to get it), all the new terms people were
coming up with to describe things we already had or already did, the
cryptic nature of the languages many programmers ended up making the
popular choice, finding source code that took forever to use because the
programmer didn't comment it and other issues that I just got tired of
dealing with. I still dabble sometimes but do it my way, not the way
"modern" programmers do.

Michael AppleWin Debugger Dev

2022-06-07 20:38:47 UTC

Post by Jeff Blakeney
Perhaps *you* should stop whining because someone else doesn't agree
with your opinion?

Everyone is free to share their opinion on the internet. If you don't like it, move on.

Post by Jeff Blakeney
Kent doesn't like or want to use GitHub and that is
his opinion and choice.

And water is wet.

Post by Jeff Blakeney
Trying to insult him for it makes you look
petty and mean

Where did I insult him? Did you miss the emoticons?

Post by Jeff Blakeney
You could have just posted what you think are the
benefits of it instead of talking down to those who don't agree with you.

I *did* list the benefits. Do you want them listed *again?*

Post by Jeff Blakeney
I too don't see the need for such a system as I have never been involved
in large, collaborative programming projects.

SCM are handy even if you are only on a 1 person project. Yes, there is some overhead, but that is minor to the benefits it provides.

Amateur programmers tend to make excuses for avoiding SCM. i.e. They think "backup folders" are a way a to "manage" version control.

Take CI/CD. Yes, this is a PITA to setup. For small toy projects it is a complete waste of time but eventually you reach a point of code complexity where you NEED automatic testing of code coverage and NEED to know when a build breaks. You want tools and a system that let you incorporate new features of project management. GitHub has done a pretty good with this.

Post by Jeff Blakeney
I gave on on programming for a career as I really didn't like all the extra overhead people kept adding (I need this one function so I'll add a multi-megabyte library to get it),

100% agree. That is indeed a big problem of Cargo Cult Programming: Including 1 library which includes a 2nd library which includes yet another 3rd library just to use one function that could have been written in less then 20 lines of code. One of the common Crap++ examples I use is pointing out Boost's bloated CRC code. And then people wonder why it takes an hour to compile their code.

Nothing to do with SCM though.

Post by Jeff Blakeney
all the new terms people were coming up with to describe things we already had or already did,

Yes, that is a problem. Programming tends to run in a 20 year cycle where some new hotness is reinvented because some kid didn't understand or even know the name of the old tech.

There are also times where new concepts do get invented and refined. Distributed SCM is one of those times.

Nothing to do with SCM though.

Post by Jeff Blakeney
the cryptic nature of the languages many programmers ended up making the popular choice,

Dumb programmers keep inventing new programming languages (Python, JavaScript, etc.) because they are 1/ too lazy to learn how to use the existing language, 2/ want more syntactic sugar for their pet feature while not understanding the man-years that went into debugging the entire toolchain. Except it is half-baked, tries to be a silver bullet, and ends up being over-complicated, solving some problems and ignoring all the other ones, and you are lucky if you get a functional profiler, let alone debugger. Fad X language gets popular as everyone jumps on the bandwagon. Eventually it gets abandoned as people realize all the old problems are STILL there. Some new Shiny Language Fad Y promises to fix all the old problems and rinse-and-repeat every 10 - 20 years.

Nothing to do with SCM though.

Post by Jeff Blakeney
finding source code that took forever to use because the
programmer didn't comment it and other issues that I just got tired of
dealing with.

Far too many programmers (professional and amateur) don't understand:

* Code documents HOW
* Comments document WHY

The lack of comments is a BIG problem in the industry.

The second biggest problem is shitty variable names.

I wish every professional programmer was forced to watch:

Clean Coders Hate What Happens to Your Code When You Use These Enterprise Programming Tricks

This has nothing to do with SCM though.

Post by Jeff Blakeney
I still dabble sometimes but do it my way, not the way
"modern" programmers do.

There is a HUGE difference between using a modern tool and jumping on the band wagon of fad programming. Most of "modern programming practices" are crap, reinventing solutions that existed previously that were less overengineered.

I used the analogy of git + GitHub being a power tool for a reason. It is a good one.

git + GitHub is just one superior tool (among many.) If you are a professional programmer and aren't using it then you aren't taking the time to understand WHY it exists, WHAT problems it solves, HOW it solves those problems, and how every other SCM is basically crap for versioning of code. The advantages FAR outweigh all of its problems.

The downsides of git are:

* can be complex to learn. I didn't have a problem with it but many think the learning curve is a vertical cliff. i.e. staging area.
* is useless for storing binary data. (See LFS for a workaround/solution.)
* managing multiple branches can be tedious (workspaces is one workaround/solution.)
* not everyone likes the command line (although this is less of an issue since there are numerous GUI front ends)

i.e. For game dev a perfectly reasonable solution is:

* git for code
* svn for binary assets

Good Engineering is being aware of and understanding the tradeoffs for solutions. I've never seen a better solution for SCM then git+GitHub.

Talk and LISTEN to other developers. They will share the same sentiments.

That's my opinion and you are free to ignore it. =P

m

magnusfalkirk

2022-06-08 01:01:45 UTC

Post by Michael AppleWin Debugger Dev
That's my opinion and you are free to ignore it. =P
m

I agree that we should ignore your opinion because from my point of view both of your posts can be boiled down to "He doesn't want to do it my way so he's an old idiot!" Not everyone feels the need to use git or GitHub. Maybe Kent is doing all the programming on KEGS himself and doesn't want to let anyone else add to it. I'm sure he takes suggestions, when he feels they will add to the program.

You did insult Kent at the start of your first post by saying "Translation: Old man stuck in his ways makes excuses for why they don't want to learn how modern platforms *streamline* project management." Then you also added this "Whining that "git is too hard to learn" is just stubborn laziness not wanting to learn the pros/cons of git and the entire ecosystem of what GitHub provides."

So get off your hifh horse and keep your stupid opinions to yourself. Of course feel free to ignore this post, which you probably will.

magnus

magnusfalkirk

2022-06-08 01:04:11 UTC

Post by Michael AppleWin Debugger Dev
That's my opinion and you are free to ignore it. =P
m

I agree that we should ignore your opinion because from my point of view both of your posts can be boiled down to "He doesn't want to do it my way so he's an old idiot!" Not everyone feels the need to use git or GitHub. Maybe Kent is doing all the programming on KEGS himself and doesn't want to let anyone else add to it. I'm sure he takes suggestions, when he feels they will add to the program.

You did insult Kent at the start of your first post by saying "Translation: Old man stuck in his ways makes excuses for why they don't want to learn how modern platforms *streamline* project management." Then you also added this "Whining that "git is too hard to learn" is just stubborn laziness not wanting to learn the pros/cons of git and the entire ecosystem of what GitHub provides."

So get off your high horse and keep your stupid opinions to yourself. Of course feel free to ignore this post, which you probably will.

magnus

Michael AppleWin Debugger Dev

2022-06-08 07:11:29 UTC

Post by magnusfalkirk
So get off your high horse and keep your stupid opinions to yourself. Of course feel free to ignore this post, which you probably will.

/whoosh

Michael AppleWin Debugger Dev

2022-06-08 07:10:45 UTC

If I knew what CI/CD was I might be able to know how this could be
helpful. I also don't know what code coverage is or how one could do
automatic testing of it.

CI/CD = continuous integration (CI) and continuous delivery (CD)

See this Wikipedia article for more details:
https://en.wikipedia.org/wiki/CI/CD

A few simple examples:

Your app runs on Windows, macOS and Linux. Someone commits a change. A build is automatically kicked off. When one of the platforms fails to compile an email is sent out to the person who did the commit.

Code is checked in. The automatic build systems compiles and everything is good. However one of the automatic tests that do fuzz testing fail. An email is sent to the person who did the commit that the code is unsafe.

As programming has evolved from being done by hobbyists to professionals and as software development has matured from being done be code monkeys to software engineers it has allowed us to write more and more complex programs. This increased complexity has caused an combinatorial explosion of testing. There is a movement to automate testing and "fail fast" -- catch as many mistakes as early as possible.

CI/CD is NOT a silver bullet. It just another tool to help catch bugs proactively and reactively. One could certainly waste all your time setting up automatic testing and have nothing to show for it.

This is why statically-typed languages such as C/C++ are god and dynamically-typed liked languages such as JavaScript are shit for production. In JavaScript you can misspell variables names and not even know it unless you use the stupid "use strict"; hack. It is BASIC all over again. The industry is littered with badly practices because there was "never time to do it right."

Figuring out *when* a build breaks is easy. It is when you compile the
project and it doesn't work properly. Yes, this is an over
simplification as problems may not be noticed until several versions
down the line. Figuring out *why* it doesn't work is the hard part.

Generally I agree with this 99% however "breaks" is a bit of complicated subject. There are many types of failures (loosely from simplest to hardest):

* code fails to compile -- trivial to catch
* code compiles on one compiler, doesn't one another one -- sometimes requires being a language lawyer, working around different language support, etc.
* code compiles, but automatic tests fail
* code compiles, automatic tests pass, but there are regressions (new or old)
* a new driver breaks working code
* hardware errors causing a failure. Drive dies, becomes full, etc.

What makes programming SO time consuming is dealing with all the edge cases while not ending up in pedantic hell of trying to catch every single one.

But yeah, you spend days tracking down a bug and then 30 minutes to fix it. /s

git has an amazing tool called git bisect. You can use it to track down:

* when a bug got introduced, or the "inverse"
* when a feature got introduced.

still programming for a living and he keeps telling me about the awful things he has to put up with because the people he is programming for want them done that way.

Yup, that is a common problem in the industry. Many old software engineers get tired of the same old bullshit and leave for more mature fields. I don't blame them.

Management is part of the problem:

* clinging to out dated methodologies,
* don't want to invest in new tools or methodologies,
* don't want to invest in the R&D to innovate
* change the product for the sake of change trying to justify their jobs

It doesn't help that you have fads like Agile and then everyone misses the entire fucking point by having useless daily standup meetings that drag on for an hour.

Another great tool is static analysis. There are amazing at catching all sorts of "hidden" bugs. If you are a professional and not using one you are being an amateur code monkey. Coverity is one of the bigger ones. PVS-Studio is amazing for catching inconsistent naming and typos. The fundamental problem is ALL (useful) software has bugs. The problem isn't the bugs you know about but the ones you don't know about.

Wikipedia has a great list:
https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

Part of being a great software engineering is knowing what old methodologies to keep and what new ones to embrace.

Looking at mame's page on GitHub ...

https://github.com/mamedev/mame

... I see it has 1600 forks. I'd say that is a pretty successful project of collaboration!

If some developer doesn't want to learn how to use git+GitHub then it is hard to take their whining seriously when so many other developers understand the benefits of using modern tools.

For Nox Archaist we used git+GitHub and it was REALLY nice.

One of THE biggest problems projects have, especially Open Source ones, is what I call "build friction". A project should EASILY be able to be built "out of the box". If it requires jumping through a dozen hoops just to build the damn thing chances are people aren't going to waste their time trying to figure this shit out. For starters there should be either a "make" (for Un*x systems) or a Visual Studio Solution file (for Windows projects) that "just compiles". The lower the barrier of entry for building a project the easier it is to get people to contribute.

That's why I think people who make excuses for "git is too hard" are being extremely short-sighted. They don't want to invest the 10% effort to get the 90% benefits so they waste their time doing 80% more work.

Popularity is usually a shitty metric for quality (the billions served by McDonalds is the perfect example), but in git's case it is 100% accurate. It is very rare for a single programmer to redefine the entire software industry, twice, let alone once.

m.

Kent Dickey

2022-06-13 04:39:42 UTC

You trimmed it out, but I'm putting in my entire reference to GIT:

---
I am not planning to move to GitHub for KEGS revision control. I've managed
to avoid using Git in any serious way yet, and I see no reason to do so now.
Git has created a whole slew of ridiculous jargon ("pull request") and I
dislike it for lots of reasons. I don't want to discuss this since I am
tired of being spoken down to like I'm an idiot for not using Git.
And if I put KEGS on github, then I'll have to deal with submissions through
git, and I don't want that.
---

Post by Kent Dickey
Git has created a whole slew of ridiculous jargon

Translation: Old man stuck in his ways makes excuses for why they don't
want to learn how modern platforms *streamline* project management. /s

[ long rant snipped]

I mentioned not liking Git briefly a while ago, and you ranted at me then,
and I was asking you not to this time.

I've said very little about Git, and you've gone on a long rant about
some imagined idea of what I might think.

Keep using Git, I hope it makes you happy. I think that one can do quality
programming and not use Git, and not be in the dark ages either. Proof:
something will come along and replace Git eventually, right? Git solves
problems I don't have, and it causes problems I don't want.

Kent

Michael AppleWin Debugger Dev

2022-06-14 03:49:17 UTC

Post by Kent Dickey
something will come along and replace Git eventually, right?

This demonstrates you don't understand the _first_ thing about git and the problems it solves. This is almost as stupid as saying "But something will replace Linux, right!"

1. It will take a _minimum_ of 20-40 *years* before someone attempts to replace git.

* No company will waste resource developing a replacement which means it will be done by open source developers. (With MS owning GitHub they certainly won't abandon it for something else since back in 2017 they ditched Perforce for git almost 100%. Apple, Google, Amazon, won't reinvent the wheel either.)
* No open source developers are going to waste their time re-inventing the SCM wheel.
* IF by some miracle someone actually wrote a git replacement in that time the git / GitHub ecosystem will have grown so much and the bar raised so much that it would be a complete waste of time.
* What I could see is a a dumbed down "git lite" for developers who can't understand git.

2. The biggest problem _isn't_ with git but with the UI. There will always more yet-another pretty GUI frontends for it to streamline common operations.

git is revolutionary, not evolutionary, which is why it took developers by storm. Maybe learn about it before making idiotic statements.

Michael

I am Rob

2022-06-14 17:44:37 UTC

Only insecure morons say things like "as stupid as" or "making idiotic statements". WTH is the matter with you Michael?
You have absolutely NO credibility that anyone should read what you have to say. Stay off these forums if you got nothing intelligent to say.

Brandon Taylor

2022-06-14 23:21:19 UTC

AND with that, I'd like to call for this thread to be shut down. I am NOT, for the life of me, going to stand in the middle of senseless bickering over nothing.

I am Rob

2022-06-15 04:18:46 UTC

AND with that, I'd like to call for this thread to be shut down. I am NOT, for the life of me, going to stand in the middle of senseless bickering over nothing.

And it is because of your decision is why the bully always wins. This used to be a pretty good community, but it is the usage of some peoples choice of words that poisoned any subject that was brought up. Sitting on the fence and saying "for the life of me" you don't want to get involved, is also what kills this forum. It is not senseless bickering when you stand up to a bully.

I used to be like you not getting involved in disputes. But then there was nothing. No one was willing to even post a comment or question. I stand up to bullies with the hopes to keep this forum alive so people like you can post freely and have meaningful conversations without repercussion. How far are you willing to go to stand up for something you want to be an active part in?

Michael AppleWin Debugger Dev

2022-06-14 23:47:28 UTC

Post by I am Rob
You have absolutely NO credibility that anyone should read what you have to say.

I know "nothing" about git after 8 years of using it as opposed to someone who doesn't even use it. I know nothing about SourceSafe, SVN, Alienbrain, Perforce having used all of them for years. /s

Post by I am Rob
Stay off these forums if you got nothing intelligent to say.

I'm sorry, I missed the memo that this was _your_ forum.

If _only_ there was a way to ignore posts about a developer calling out another developer making ignorant statements about git. To bad there wasn't a way to learn how to use a kill file. /s

But "Thanks" for cluttering up this thread with even more useless ad hominem noise instead of discussing the Pros & Cons of SCM that you have actually _used._

Maybe someday you'll stop shooting the messenger and learn to read the message. Maybe.

Michael

Jeff Blakeney

2022-06-15 03:39:35 UTC

Post by I am Rob
You have absolutely NO credibility that anyone should read what you have to say.

I know "nothing" about git after 8 years of using it as opposed to
someone who doesn't even use it. I know nothing about SourceSafe,
SVN, Alienbrain, Perforce having used all of them for years. /s

First, the /s thing was bugging me so I finally looked it up to find out
it denotes sarcasm.

Second, I am Rob didn't say you didn't know anything, just that you have
lost a lot of credibility and some of use don't really want to read your
messages anymore.

Post by I am Rob
Stay off these forums if you got nothing intelligent to say.

I'm sorry, I missed the memo that this was _your_ forum.

I am Rob's statement is pretty far off of what usenet is all about.
There is no requirement that posts here need to be intelligent. :)

Post by Michael AppleWin Debugger Dev
If _only_ there was a way to ignore posts about a developer calling
out another developer making ignorant statements about git. To bad
there wasn't a way to learn how to use a kill file. /s
But "Thanks" for cluttering up this thread with even more useless ad
hominem noise instead of discussing the Pros & Cons of SCM that you
have actually _used._

This thread started with someone wondering if work was still being done
on GSport and GSplus and whether the features they have added could
somehow be brought back to KEGS as Kent has been actively working on it
again. Some of the messages here have been about that and how to
accomplish such things.

However, when Kent said he had no plans to use Git for handling his
source code, and even gave some reasons why, you started insulting him
for not wanting to use your preferred system. You have been cluttering
this thread with hints and jargon about all the great things that Git
can do which is not what this thread is about.

Post by Michael AppleWin Debugger Dev
Maybe someday you'll stop shooting the messenger and learn to read the message. Maybe.

This thread would have been much shorter if you hadn't taken personal
affront to someone saying they didn't like Git and "shooting the
messenger". You could have been civil and simply posted your opinion.
When that didn't change people's minds you could have just moved on.

The only reason I got involved in the thread was because you were
attacking Kent for no good reason and to show you that he isn't the only
one who has no interest in using Git.

I have considered writing my own IIgs emulator to get features I want
because I'm a Windows user and I don't think Kent is doing updates for
Windows anymore. I prefer not to use any of the C or Java languages and
trying to get things set up and get it to compile properly is a pain.
If I do write my own emulator it would be written in a language called
PowerBASIC and I'm not sure if it is still available as the original
author/owner passed away.

I am Rob

2022-06-15 04:50:54 UTC

Post by Jeff Blakeney

Post by I am Rob
Stay off these forums if you got nothing intelligent to say.

I'm sorry, I missed the memo that this was _your_ forum.

I am Rob's statement is pretty far off of what usenet is all about.
There is no requirement that posts here need to be intelligent. :)

I just want to clarify my use of the word "intelligent" here. It was supposed to indicate "intelligent language" as in, by not using derogatory language to belittle another person. The unnecessary language in question was put into quotes. ( "as stupid as" or "making idiotic statements").

Also, just an FYI, this is not just about the essence of Usenet. There are other Readers for these groups. I use Google Groups. Doesn't mean I have the right to use derogatory language against anyone using Usenet just for the sake of it. just because it allows free speech. That essence is what basically poisoned this group.

Charlie

2022-06-15 15:50:52 UTC

Post by Kent Dickey
something will come along and replace Git eventually, right?

This demonstrates you don't understand the _first_ thing about git and the problems it solves.

Non sequitur.

Post by Michael AppleWin Debugger Dev
This is almost as stupid as saying "But something will replace Linux, right!"

Linux has been replaced. Android.

Post by Michael AppleWin Debugger Dev
1. It will take a _minimum_ of 20-40 *years* before someone attempts to replace git.

Please send me the winning numbers for the Powerball lottery. ;-)

Post by Michael AppleWin Debugger Dev
* No company will waste resource developing a replacement which means it will be done by open source developers.

Ever hear of Google? I don't believe they use GIT. I believe they use
Piper (which they developed) but of course you knew that.

Post by Michael AppleWin Debugger Dev
(With MS owning GitHub they certainly won't abandon it for something else since back in 2017 they ditched Perforce for git almost 100%.
Apple, Google, Amazon, won't reinvent the wheel either.)

I don't have as much faith in MicroSoft as you.

Post by Michael AppleWin Debugger Dev
* No open source developers are going to waste their time re-inventing the SCM wheel.

I don't know anything about SCM but I've seen a lot of 'wasted time'
open source projects.

Post by Michael AppleWin Debugger Dev
* IF by some miracle someone actually wrote a git replacement in that time the git / GitHub ecosystem will have grown so much and the bar
raised so much that it would be a complete waste of time
* What I could see is a a dumbed down "git lite" for developers who can't understand git.
2. The biggest problem _isn't_ with git but with the UI. There will always more yet-another pretty GUI frontends for it to streamline common operations.
git is revolutionary, not evolutionary, which is why it took developers by storm. Maybe learn about it before making idiotic statements. >
Michael

We get it. You like Git.

As I understand it, version control software was made because people
couldn't keep their own versions straight causing a lot of confusion.
If that is your problem then maybe GIT is for you.
I can understand that. It happens to me. I haven't tried GIT yet.

But then I'm an "Old man stuck in his ways..." ;-)
And here's my excuses for why I "don't want to learn how modern
platforms *streamline* project management":

1. I like programming (it's my hobby). I don't like project management
(sounds like work to me).

2. Over the years I've spent a lot of time learning a lot of things that
weren't worth it. So I get a little gun shy when 'everyone' moves to
the latest, greatest thing since buttered bread.
--------------

Also, since you have spent time learning GIT / GIThub maybe you could
spend some time learning how to interact with people.
You obviously have knowledge that is valuable to this group but you come
off as very immature.

Charlie

Michael AppleWin Debugger Dev

2022-06-15 16:16:55 UTC

Post by Michael AppleWin Debugger Dev
This is almost as stupid as saying "But something will replace Linux, right!"

Linux has been replaced. Android.

Huh?

1. In the *mobile* space Android runs on TOP of the Linux kernel powering 2+ Billion devices. (We'll have to wait and see if Google replaces Linux with Fuschia OS)

2. In the *supercomputer* space Linux has run on 100% of the Top 500 Supercomputers in the world since 2017.
https://www.top500.org/statistics/details/osfam/1/

3. In the *desktop* space Linux has around 5% usage if stats are accurate. The "Year of the Linux Desktop" has been joked about since the early 2000's and probably will never happen unless MS changes. With 66% of Azure running Linux now who knows what will MS do? There has been wild speculation over the years that MS will eventually drop the NT Kernel but I've never seen anything concrete.

Not too shabby for an OS that "won't be big and professional like gnu".

But this is OT.

Michael

Charlie

2022-06-15 17:20:15 UTC

Post by Michael AppleWin Debugger Dev
This is almost as stupid as saying "But something will replace Linux, right!"

Linux has been replaced. Android.

Huh?
1. In the *mobile* space Android runs on TOP of the Linux kernel powering 2+ Billion devices. (We'll have to wait and see if Google replaces Linux with Fuschia OS)
2. In the *supercomputer* space Linux has run on 100% of the Top 500 Supercomputers in the world since 2017.
https://www.top500.org/statistics/details/osfam/1/
3. In the *desktop* space Linux has around 5% usage if stats are accurate. The "Year of the Linux Desktop" has been joked about since the early 2000's and probably will never happen unless MS changes. With 66% of Azure running Linux now who knows what will MS do? There has been wild speculation over the years that MS will eventually drop the NT Kernel but I've never seen anything concrete.
Not too shabby for an OS that "won't be big and professional like gnu".

The point I was trying to make was that Linux is replaced with each
significant change in the kernel and for the desktop the different
distributions.

I used Android as an example because it uses a *modified* Linux kernel.
To me that is a replacement.

Post by Michael AppleWin Debugger Dev
But this is OT

Yes.

Post by Michael AppleWin Debugger Dev
Michael

Charlie

Steve Nickolas

2022-06-15 17:43:34 UTC