[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ML] Hosting of gnustep.org
From: |
H. Nikolaus Schaller |
Subject: |
Re: [ML] Hosting of gnustep.org |
Date: |
Thu, 21 Jan 2021 21:54:20 +0100 |
> Am 21.01.2021 um 19:49 schrieb Ivan Vučica <ivan@vucica.net>:
>
> On Tue, Jan 19, 2021 at 7:23 PM H. Nikolaus Schaller <hns@goldelico.com>
> wrote:
>>> Footer links to https://projects.goldelico.com/p/swi/. This is fine,
>>> but the path to contributing should be clearer.
>>
>> Indeed.
>>
>> Alternatively if you have access to cvs.savannah.gnu.org:/web/gnustep
>> you should find it in /softwareindex.
>
> CVS! Eek.
>
>>
>> By the way since you are complaining: it *is* in the GNUstep repo:
>>
>> https://github.com/gnustep/gnustep.github.io/tree/master/softwareindex
>
> I'm not complaining -- however if I wanted to work on it (e.g. clean
> up by switching to PDO and placeholders instead of worrying if quoting
> function was called and worrying if it does the right thing for a
> particular input and for a particular language:
> https://ef.gy/php-use-pdo), I wouldn't know what's the "standard"
> version of the code that can be deployed.
>
>>
>> Oops. Even with a security issue I do not want to explain here.
>> Whom should I contact to remove a file from there including the index?
>
> Do we need to rewrite history or can the security issue be fixed
> without such measures? Rewriting git history is possible, but tedious
> and possibly dangerous. (Anyone who cloned a copy of the repo will get
> offered `merge` by default and might push back the old history.)
>
> Is the security issue present in the Savannah / projects.goldelico.com
> copy? Rewriting history in CVS would likely be infeasible without help
> from Savannah admins.
>
> Can you fix the issue without a history rewrite? Can we just delete
> the code in the current commit?
>
>> And, that there are two logins. I have no idea if that can be harmonized.
>
> Technically, oauth login to Github + org membership check, if you
> really wanted to do it.
> https://docs.github.com/en/rest/reference/orgs#check-organization-membership-for-a-user
>
>> Well, my dream is to write WebApps in Obj-C using OpenSTEP classes.
>> I.e. button = [[NSButton alloc] initWithTitle:@"press here"]; and have
>> the GUI class NSButton emit the necessary HTML+CSS+JS to present it to
>> the user so that he can press the button in his browser. So use the MVC
>> model in the App completely hiding that the user-interaction goes through
>> https (on a very abstract level there is no big difference between http
>> and X11 protocols connecting a server over the network with a display
>> and a keyboard).
>>
>> This could be achieved by a compiler from Obj-C to PHP or directly to
>> PHP byte-code...
>
> No translation into PHP needed. Simply implement an API in whatever
> language pleases you,
What about Objective-C?
> and the web UI in Cappuccino framework. You get
> the full AppKit in the browser as a single-page app.
>
> Of course, that's completely unindexable by search engines, so it's
> only suitable for applications (e.g. administrative tools), not for
> presentation of content.
>
> But if you're going to work on presenting content, you need a
> templating system for content, not a UI framework. And implementing
> administrative UI in a Javascript-heavy framework may raise some
> people's eyebrows; but if you'll do something Javascript-free, then
> again, doing OOP UI just so you can render a static page and maintain
> some basic state in sessions is an overkill.
Neither nor. I have such a system running for my own web pages...
The only drawback is that I have to do the same thing as Apple did
with Cocoa Java bindings long ago but with PHP. I.e. instead of writing
view=[[NSTableView alloc] initWithFrame...];
[view setDataSource:something];
[view setDoubleAction:@selector(doubleAction:)];
I have to write something like
$view=new NSTableView()->initWithFrame...;
$view->setDataSource($something);
$view-> setDoubleAction("doubleAction");
Missing is a translator from the first to the second format which
a PHP installation can render to a screen (by using http+html instead
of ssh+xprotocol or display postscript etc.).
>
>>> Additionally, widest deployed Fediverse services are
>>> written in Ruby and Elixir respectively.
>>
>> Generally this is a Not Invented Here phenomenon.
>
> Choosing among a variety of languages feasible for web development is
> not an example of NIH.
I mean developing a new language where others exist are maintained are
turing complete do what they have been designed for etc.
>
> To be more direct: choosing non-PHP, non-Apache2 and non-MySQL is not NIH.
I do not mean choosing but inventing (the I is "invented") something new
instead of fixing the existing.
>
> At this time, anything new web-oriented I'm writing is using Go, nginx
> and PostgreSQL (or, in one toy project case, local file storage).
I wonder what is better there? What has not been possible before? And
choosing MySQL or PostgreSQL is just a matter of choice in some config
file.
Hm. Why is anyone considering to use Obj-C and GNUstep to write desktop
apps? Everone writing something new is using other languages. Including
Go, Python etc.
So I am really astonished to read this argument within the context of
a project that keeps a vintage (and IMHO still the best one) system alive.
But we are far off the original topic: "Hosting of gnustep.org"
>
>> And since they do
>> not have a need to cooperate any more they compete. By inventing new
>> languages and making developers depend on them. If they would use
>> all the same language, developer would go away quicker. Standard
>> process in economics...
>
> I was pointing out they're not using PHP. There must be some reasons
> why people rarely pick PHP as a tool these days?
Are they? Is there a statistics or is this a personal view?
>
> I mean, consider the major reason why people used to pick it up: it's
> been popular due to availability of cheap shared hosting services, and
> because it was one of the easiest things to integrate with apache2.
And sufficient.
> These days, apache2 isn't the default choice for a front server:
> that's nginx. https://news.netcraft.com/archives/category/web-server-survey/
To be honest, I never had any issue with Apache to solve by ngnix.
> In addition, there's an abundance of cheap hosting systems that we can
> really do better than an metastasized templating engine. (Unless
> you're actually writing OOP PHP, unit testing everything, etc -- at
> which point you've adopted so many good engineering practices you
> might as well be using another language. And probably should.)
Yes, I write PHP that way. Using the mySTEP.php framework mentioned
above. I use MVC paradigm and OpenSTEP classes.
> Please don't tie yourself to running everything on PHP or generating
> PHP from a language you create.
Why not? PHP is an intermediate language. Like assembler. Can be changed
in the long run when people demand.
> Running an extra binary and having
> something like systemd (or even just a silly infinite-loop bashscript)
> autorestart it is not a big deal, and allows you to isolate
> application functionality into multiple unix users, in particular -- a
> distinct one from the frontend server (whether nginx or apache2 or
> whatever you want to put in front on the multiplexed serving port).
So let's help Greg to solve the real issue: "Hosting of gnustep.org".
- Re: [ML] Hosting of gnustep.org, (continued)
- Re: [ML] Hosting of gnustep.org, Ivan Vučica, 2021/01/19
- Re: [ML] Hosting of gnustep.org, H. Nikolaus Schaller, 2021/01/19
- Re: [ML] Hosting of gnustep.org, Ivan Vučica, 2021/01/19
- Re: [ML] Hosting of gnustep.org, H. Nikolaus Schaller, 2021/01/19
- Re: [ML] Hosting of gnustep.org, H. Nikolaus Schaller, 2021/01/19
- Re: [ML] Hosting of gnustep.org, Ivan Vučica, 2021/01/19
- Re: [ML] Hosting of gnustep.org, H. Nikolaus Schaller, 2021/01/19
- Re: [ML] Hosting of gnustep.org, Ivan Vučica, 2021/01/21
- Re: [ML] Hosting of gnustep.org,
H. Nikolaus Schaller <=
- Re: [ML] Hosting of gnustep.org, address@hidden, 2021/01/21
- Re: [ML] Hosting of gnustep.org, H. Nikolaus Schaller, 2021/01/22