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?
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.
On 5/4/22 11:34 AM, Brandon Taylor wrote: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?
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...
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.
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?
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.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
On Saturday, May 7, 2022 at 2:17:35 PM UTC-5, mmphosis wrote:
Okay. So, Kent, would you be open to posting KEGS to GitHub so you andCompare away, it's here:
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?
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.
On 5/7/22 8:35 PM, Brandon Taylor wrote: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.
On Saturday, May 7, 2022 at 2:17:35 PM UTC-5, mmphosis wrote:
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
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.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.
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.--- Synchronet 3.21b-Linux NewsLink 1.2
On Wednesday, May 4, 2022 at 1:07:09 PM UTC-5, schmidtd wrote:
On 5/4/22 11:34 AM, Brandon Taylor wrote:repository pages for GSport and GSPlus, two forks of KEGS. I've noticed
My question is kind of a two-parter. I've looked at the GitHub
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 incessantcould fork some of the source code from them and integrate it into
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...
And now, Kent Dickey, if these projects ARE dead, do you think you
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.
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?
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.)
In article <5b5be245-d444-4aaa...@googlegroups.com>,
Brandon Taylor <br.ta...@gmail.com> wrote:
On Wednesday, May 4, 2022 at 1:07:09 PM UTC-5, schmidtd wrote:
On 5/4/22 11:34 AM, Brandon Taylor wrote:future versions of KEGS? I for one would love to see you add emulation
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...
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
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.
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
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.
Git has created a whole slew of ridiculous jargonTranslation: Old man stuck in his ways makes excuses for why they don't want to learn how modern platforms *streamline* project management. /s
"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?
Translation: Old man stuck in his ways makes excuses for why they[snip]
don't want to learn how modern platforms *streamline* project
management.
Whining that "git is too hard to learn" is just stubborn laziness not[snip]
wanting to learn the pros/cons of git and the entire ecosystem of
what GitHub provides.
Perhaps *you* should stop whining because someone else doesn't agreeEveryone is free to share their opinion on the internet. If you don't like it, move on.
with your opinion?
Kent doesn't like or want to use GitHub and that isAnd water is wet.
his opinion and choice.
Trying to insult him for it makes you lookWhere did I insult him? Did you miss the emoticons?
petty and mean
You could have just posted what you think are theI *did* list the benefits. Do you want them listed *again?*
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 involvedSCM 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.
in large, collaborative programming projects.
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.
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.
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.
finding source code that took forever to use because theFar too many programmers (professional and amateur) don't understand:
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 wayThere 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.
"modern" programmers do.
That's my opinion and you are free to ignore it. =PI 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.
m
That's my opinion and you are free to ignore it. =PI 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.
m
On Tuesday, June 7, 2022 at 11:09:13 AM UTC-7, Jeff Blakeney wrote:
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.
Kent doesn't like or want to use GitHub and that is his opinion and
choice.
And water is wet.
Trying to insult him for it makes you look petty and mean
Where did I insult him? Did you miss the emoticons?
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?*
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.
Nothing to do with SCM though.[snip]
That's my opinion and you are free to ignore it. =P
If I knew what CI/CD was I might be able to know how this could beCI/CD = continuous integration (CI) and continuous delivery (CD)
helpful. I also don't know what code coverage is or how one could do automatic testing of it.
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 overGenerally I agree with this 99% however "breaks" is a bit of complicated subject. There are many types of failures (loosely from simplest to hardest):
simplification as problems may not be noticed until several versions
down the line. Figuring out *why* it doesn't work is the hard part.
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.
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.
On Thursday, June 2, 2022 at 2:04:30 PM UTC-7, Kent Dickey wrote:
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.
On Thursday, June 2, 2022 at 2:04:30 PM UTC-7, Kent Dickey wrote:
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
But...I also don't want other people commercializing and selling KEGS.Why not?
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.
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.
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.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.
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.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.
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.
Proof: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!"
something will come along and replace Git eventually, right?
Only insecure morons say things like "as stupid as" or "making idiotic statements". WTH is the matter with you Michael?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.
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.
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.
On Tuesday, June 14, 2022 at 10:44:38 AM UTC-7, I am Rob wrote:
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
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.
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.Only insecure morons say things like "as stupid as" or "making idiotic statements". WTH is the matter with you Michael?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.
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.
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").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. :)
On Sunday, June 12, 2022 at 9:39:43 PM UTC-7, Kent Dickey wrote:
Proof:
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
Huh?This is almost as stupid as saying "But something will replace Linux, right!"Linux has been replaced. Android.
On Wednesday, June 15, 2022 at 8:50:57 AM UTC-7, Charlie wrote:
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
On 6/13/2022 11:49 PM, Michael AppleWin Debugger Dev wrote:<snip>
This is almost as stupid as saying "But something will replace Linux,
right!"
Linux has been replaced. Android.
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.
On Sunday, June 12, 2022 at 9:20:46 PM UTC-7, Kent Dickey wrote:
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.
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.
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 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.
On Sunday, June 26, 2022 at 2:49:08 PM UTC-7, Kent Dickey wrote:
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.
You mention a non-open-source license that lets people compile code:"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.)
What license would this be?
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 59 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 18:05:17 |
| Calls: | 810 |
| Calls today: | 1 |
| Files: | 1,287 |
| D/L today: |
10 files (21,017K bytes) |
| Messages: | 193,396 |