I suggest to make it unmanaged and remove PGP key & administrativestuff. Unless someone has a better advice about that?
As we speak of historic hierarchies (net.*), the microsoft.* one has
also been stalled since 2009 when the msnews.microsoft.com server was
shut down. Nonetheless, the newsgroups are still in the wide, and some
of them are active. So maybe microsoft.* should remain in control.ctl
but the comment adapted?
# Control articles for that hierarchy are not issued by Microsoft itself
# but by a Usenet active participant in order to improve the quality of
# the propagation of Microsoft newsgroups. Their official URL is:
# http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx
I suggest to make it unmanaged and remove PGP key & administrativestuff. Unless someone has a better advice about that?
P.-S.: I wonder whether gnu.* couldn't similarly be checked and
updated. As well as perl.* or linux.* list of mailing-list gateways.
As we speak of historic hierarchies (net.*), the microsoft.* one has
also been stalled since 2009 when the msnews.microsoft.com server was
shut down. Nonetheless, the newsgroups are still in the wide, and some
of them are active. So maybe microsoft.* should remain in control.ctl
but the comment adapted?
# Control articles for that hierarchy are not issued by Microsoft itself
# but by a Usenet active participant in order to improve the quality of
# the propagation of Microsoft newsgroups. Their official URL is:
# http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx
I suggest to make it unmanaged and remove PGP key & administrativestuff. Unless someone has a better advice about that?
Well, I think it's partly up to you whether you want to continue to
maintain the hierarchy. If you don't, then making it unmanaged makes
sense, and I can understand why you may not want to take on management of
the hierarchy rather than just relaying Microsoft's group list.
That said, it's still in active use, so having a source of a canonical
group list is useful. So would pruning out the groups that no one is
using if anyone felt like doing that. Obviously, you don't have to take
that on and anyone who does that doesn't even need to use the same private key (we can always update configurations later), but it might be an easier transition to keep using the same one.
- trying to give it a new impulse and sending control messages to create newsgroups from the products seen in the new Microsoft Community web
forums <https://answers.microsoft.com/>
I'm wondering whether there couldn't be legal issues with that
(maintaining a list of microsoft.public.* newsgroup names matching
Microsoft products, now that the officiel msnews.microsoft.com server is
no longer here).
Hi all,
As we speak of historic hierarchies (net.*), the microsoft.* one has
also been stalled since 2009 when the msnews.microsoft.com server was
shut down.
Nonetheless, the newsgroups are still in the wide, and some of them are active.
So maybe microsoft.* should remain in control.ctl but the comment adapted?
# Control articles for that hierarchy are not issued by Microsoft itself
# but by a Usenet active participant in order to improve the quality of
# the propagation of Microsoft newsgroups. Their official URL is:
# http://www.microsoft.com/communities/newsgroups/list/en-us/default.aspx
I suggest to make it unmanaged and remove PGP key & administrativestuff. Unless someone has a better advice about that?
Web forums (https://answers.microsoft.com/) are now used by Microsoft.
I doubt the PGP key will ever serve again. Its purpose was to propagate changes made to the official newsgroups from msnews.microsoft.com.
I still have the private key, though, and will consider deleting it.
Julien ?LIE
I'm wondering whether there couldn't be legal issues with that
(maintaining a list of microsoft.public.* newsgroup names matching
Microsoft products, now that the officiel msnews.microsoft.com server is
no longer here).
For what it's worth, not exactly the same thing but close, years ago one of our clients registered the domain name microsoftsucks.com or
microsoftsux.com and within 2 days of creation we received legal threats.
So they do seem touchy about it.
I'm wondering whether there couldn't be legal issues with that
(maintaining a list of microsoft.public.* newsgroup names matching
Microsoft products, now that the officiel msnews.microsoft.com server is
no longer here).
but I only want to say that the newsgroup
    microsoft.public.windowsxp.general
still is *THE* most busiest English language newsgroup about Windows-XP.
In 2021 per month: 100, 104, 86, 61, 315 messages.
In june 2021 already 298 messages.
Thousands of newsgroups will be jealous about those figures :-)
I remember that I had installed the microsoft newsserver.
When they switched off, we simply followed all
microsoft.* newsgroups on other newsservers.
I thought it was in 2013, but Wikipedia says june 2010.
If I understand correctly, you want to introduce new microsoft.*
newsgroups?
Main English language newsgroups for other Windows OS are:
    alt.windows7.general
    alt.comp.os.windows-8
    alt.comp.os.windows-10
For me (and a lot of other people) webforums are no alternative to usenet.
Maybe I could send a message in a few active newsgroups to probe what
still existing users want. They may already have an idea of useful newsgroups to create.
Responding to myself,
Maybe I could send a message in a few active newsgroups to probe what
still existing users want. They may already have an idea of useful >>newsgroups to create.
In the thread "Survey about microsoft.* newsgroups" in >microsoft.public.windowsxp.general >(<news:sbi7j3$r53$1@news.trigofacile.com>), 4 persons answered.
Basically, they do not see any point in creating new newsgroups in >microsoft.* because they already have newsgroups in alt.* for new
Microsoft products.
A few legacy newsgroups like the one for Windows XP are still used in
the microsoft.* hierarchy. People don't mind reading newsgroups from >different hierarchies (alt.*, microsoft.*, comp.*, local ones...) in
their news reader.
Note to Jason: they spoke about the difficulty to add groups to comp.*
(a hierarchy which would otherwise have been likely to be used to
discuss current Microsoft products). There are still Windows 95
newsgroups in comp.*; hope the new Big Eight board will give more
freshness to the hierarchy.
Currently, they prefer to go on adding groups in alt.* that suit their
needs.
And the other point for microsoft.* is the removal of dead groups (where
no one would respond to a question posted to them, even though they seem >empty). There is no consensus. It is either "no, don't touch the
hierarchy" or "why not, if dead, a clean up would be good".
To put into a nutshell, I am under the impression people got used to
using other hierarchies than microsoft.* and it is not obvious that
there is a wish to resurrect it...
Julien, you did too good a job convincing people that microsoft.public.* would be a nonviable hierarchy once the Microsoft News server was taken
off line, so no one made any serious attempts to start groups for
subsequent Microsoft products there. You took that option off the table.
Hi Adam,
Julien, you did too good a job convincing people that microsoft.public.* >>would be a nonviable hierarchy once the Microsoft News server was taken
off line, so no one made any serious attempts to start groups for >>subsequent Microsoft products there. You took that option off the table.
We're speaking of discussions that took place more than a decade ago.
I am not under the impression I "took that option off the table". I
just sent a final checkgroups for the remaining ~500 groups still
active, that is to say the last ones that remained in
msnews.microsoft.com several months.
. . .
Julien, you did too good a job convincing people that microsoft.public.* >>> would be a nonviable hierarchy once the Microsoft News server was taken
off line, so no one made any serious attempts to start groups for
subsequent Microsoft products there. You took that option off the table.
We're speaking of discussions that took place more than a decade ago.
I am not under the impression I "took that option off the table". I
just sent a final checkgroups for the remaining ~500 groups still
active, that is to say the last ones that remained in
msnews.microsoft.com several months.
I thought I recalled you had sent rmgroups for the remaining groups.
My error. I apologize.
P.-S.: I wonder whether gnu.* couldn't similarly be checked and
updated. As well as perl.* or linux.* list of mailing-list gateways.
I think Marco still actively maintains linux.*, although I may be wrong.
I created a key for gnu.* eons ago and was going to help maintain it, but then never finished the project and it's long-since defunct.
I just sent a final checkgroups for the remaining ~500 groups still
active, that is to say the last ones that remained in
msnews.microsoft.com several months.
I thought I recalled you had sent rmgroups for the remaining groups.
In the thread "Survey about microsoft.* newsgroups" in microsoft.public.windowsxp.general (<news:sbi7j3$r53$1@news.trigofacile.com>), 4 persons answered.
Basically, they do not see any point in creating new newsgroups in microsoft.* because they already have newsgroups in alt.* for new
Microsoft products.
A few legacy newsgroups like the one for Windows XP are still used in
the microsoft.* hierarchy. People don't mind reading newsgroups from different hierarchies (alt.*, microsoft.*, comp.*, local ones...) in
their news reader.
Currently, they prefer to go on adding groups in alt.* that suit their
needs.
Note to Jason:Â they spoke about the difficulty to add groups to comp.*
(a hierarchy which would otherwise have been likely to be used to
discuss current Microsoft products). There are still Windows 95
newsgroups in comp.*; hope the new Big Eight board will give more
freshness to the hierarchy.
Note to Jason: they spoke about the difficulty to add groups to comp.*
(a hierarchy which would otherwise have been likely to be used to
discuss current Microsoft products). There are still Windows 95
newsgroups in comp.*; hope the new Big Eight board will give more
freshness to the hierarchy.
I still reckon that if new newsgroups for Microsoft products are wished,
the comp.* hierarchy is a suitable one (besides of course alt.* where
recent newsgroups exist for latest Windows 11).
Instead of Windows 95 newsgroups still present in comp.*, a more generic
one could be useful for Windows and maybe another generic one for
Microsoft 365 products...
Following an old thread from July 2021:
In the thread "Survey about microsoft.* newsgroups" in >>microsoft.public.windowsxp.general >>(<news:sbi7j3$r53$1@news.trigofacile.com>), 4 persons answered.
Basically, they do not see any point in creating new newsgroups in >>microsoft.* because they already have newsgroups in alt.* for new
Microsoft products.
A few legacy newsgroups like the one for Windows XP are still used in
the microsoft.* hierarchy. People don't mind reading newsgroups from >>different hierarchies (alt.*, microsoft.*, comp.*, local ones...) in
their news reader.
Currently, they prefer to go on adding groups in alt.* that suit their >>needs.
As I will no longer send any control messages for microsoft.*, this
hierarchy can now be advertised as unmanaged.
. . .
I'm making the same comment here as I made in the other thread. Please
do not categorize it as "unmanaged". It's a former institutional
hierarchy. There should be no automatic processing of control messages.
Hi Adam,
I'm making the same comment here as I made in the other thread. Please
do not categorize it as "unmanaged". It's a former institutional
hierarchy. There should be no automatic processing of control messages.
"Unmanaged" means there's no longer a control.ctl entry for that
hierarchy.
The default one for control.ctl applies:
## Default (for any group)
newgroup:*:*:mail
rmgroup:*:*:mail
The list of microsoft.* newsgroups still remains in the active and
newsgroups file in ftp.isc.org.
As I suggested to keep a comment, I agree "unmanaged" is not the right
term. Maybe the term "historic" is better?
http://usenet.trigofacile.com/hierarchies/index.py?status=historic
I'm making the same comment here as I made in the other thread. Please
do not categorize it as "unmanaged". It's a former institutional
hierarchy. There should be no automatic processing of control messages.
"Unmanaged" means there's no longer a control.ctl entry for that
hierarchy.
We've always referred to alt.* and free.* as unmanaged or
unadministered. I don't think a hierarchy de-listed from control.ctl
should be referred to in that manner.
As I suggested to keep a comment, I agree "unmanaged" is not the right
term. Maybe the term "historic" is better?
In the other thread, I nominated the category "former institutional hierarchy".
I'm making the same comment here as I made in the other thread. Please >>>>do not categorize it as "unmanaged". It's a former institutional >>>>hierarchy. There should be no automatic processing of control messages.
"Unmanaged" means there's no longer a control.ctl entry for that >>>hierarchy.
We've always referred to alt.* and free.* as unmanaged or
unadministered. I don't think a hierarchy de-listed from control.ctl
should be referred to in that manner.
OK, I'll change the "unmanaged" term I used, which was not appropriate.
As I suggested to keep a comment, I agree "unmanaged" is not the right >>>term. Maybe the term "historic" is better?
In the other thread, I nominated the category "former institutional >>hierarchy".
All of the following hierarchies are not institutional ones:
http://usenet.trigofacile.com/hierarchies/index.py?status=unmanaged
I'm looking for a better term. Maybe "legacy" or "unreferenced"? (or
calling them "historic" too)
As or microsoft.*, it can fall back in the existing "historic" category.
We've always referred to alt.* and free.* as unmanaged or
unadministered. I don't think a hierarchy de-listed from control.ctl
should be referred to in that manner.
Hi Adam,
We've always referred to alt.* and free.* as unmanaged or
unadministered. I don't think a hierarchy de-listed from control.ctl
should be referred to in that manner.
I've at last reorganized the listing, following our previous discussion.
Only alt.* and free.* are now in the unmanaged page. The previously
listed ones were now in the historic section.
http://usenet.trigofacile.com/hierarchies/index.py?status=unmanaged
I've at last reorganized the listing, following our previous discussion.
Only alt.* and free.* are now in the unmanaged page. The previously
listed ones were now in the historic section.
http://usenet.trigofacile.com/hierarchies/index.py?status=unmanaged
That's reasonable. Thank you
I don't have any new comments about the categories that you haven't
heard me make in the past.
Shouldn't mod.* be a reserved hierarchy? I was going to ask about net.*
as well, but you listed it as historic.
Shouldn't mod.* be a reserved hierarchy? I was going to ask about net.*
as well, but you listed it as historic.
For example, if mod.* should be listed as reserved (which it could, like >example.*, general.* or test.*), the change to do is in the following file:
https://github.com/rra/control-archive/blob/master/config/mod
"type: defunct" should be changed to "type: reserved"
Incidentally, I see in
https://github.com/rra/control-archive/blob/master/forms/control.ctl.pre
that example.*, local.* and private.* (other already reserved groups)
could also be added to this special entry:
## Special reserved groups
newgroup:*:control|general|junk|test|to:drop >rmgroup:*:control|general|junk|test|to:drop
If you already have a list of such changes to do, you may want to put it
into an issue in https://github.com/rra/control-archive/issues
When Russ has a bit of time for that, it will facilitate the integration >instead of digging in threads in this newsgroup.
(Or course, a direct pull request with the changed files would be even
better if you happen to know how git works.)
net.* is said to be "a failed experiment which has now been abandoned"
in the comments. Would you have seen it in another category than historic? >As the control.ctl entry is "drop" for newgroup and rmgroup, it is not a >"public managed" hierarchy. I previously listed it under "public
unmanaged" but now that only alt.* and free.* are considered to be
unmanaged, I moved all these hierarchies without a control.ctl entry
with an explicit e-mail adress to the "historic" state.
Now that I've glanced at control.ctl again, two other unmanaged
hierarchies are listed:
it-alt.*
oesterreich.*
mod.* was the B News top-level hierarchy for moderated groups before[...]> I'll write up some notes and send it to github.
things were recoded so that a proto-article could be sent in email to
the moderator in the newsreader.
fa.* (from ARPANET) were gatewayed mailing lists. I have no idea how
clients worked in B News days, but I'm guessing that you had the same
problem as moderated groups, no way to send the proto-article to the
list posting address with the newsreader.
Now that I've glanced at control.ctl again, two other unmanaged
hierarchies are listed:
it-alt.*
oesterreich.*
Hi Adam,
Now that I've glanced at control.ctl again, two other unmanaged
hierarchies are listed:
it-alt.*
oesterreich.*
While looking at making the change in the web pages, I see we did not
speak about other alternative hierarchies.
Should no.alt.* and nl-alt.* also considered as "unmanaged" hierarchies?
They both have an associated PGP key but I do not know what is the
policy to create a newsgroup? Is it intended after any demand of
someone and a signed control article is then sent, or is there a
validation by a sort of Board?
no.alt.* has 41 newsgroups listed in ftp.isc.org, nl-alt.* only 3.
And what for de.alt.*? Shouldn't it be considered as "unmanaged"?
If I remember well, there's a possibility to create any newsgroup in
de.alt.* (its control.ctl entry has a doit for a newgroup control
article) and for the sake of not removing them with de.* PGP-signed >checkgroups, they are included in de.* checkgroups.
Now that I've glanced at control.ctl again, two other unmanaged
hierarchies are listed:
it-alt.*
oesterreich.*
While looking at making the change in the web pages, I see we did not
speak about other alternative hierarchies.
I had simply noticed it-alt.* and oesterreich.* in rone's unified
control.clt and your generated list. I don't have first hand knowledge.
Should no.alt.* and nl-alt.* also considered as "unmanaged" hierarchies?
They both have an associated PGP key but I do not know what is the
policy to create a newsgroup? Is it intended after any demand of
someone and a signed control article is then sent, or is there a
validation by a sort of Board?
I cannot guess what the policies are, but if the control messages
use a PGP key, even if there is some informality about adding a group to checkgroups, I'd call that "managed", given that the proponent would
never send the newgroup message himself. The keyholder has got to be considered to be the hierarchy manager for this purpose.
This has the advantage that there can be checkgroups issued regularly,
an impossibility in truly unmanaged hierarchies.
If there's a checkgroups, that provides satisfactory evidence of
hierarchy management. Similarly, a PGP key provides satisfactory
evidence of hierarchy management.
But if the proponent and not the hierarchy administrator issues newgroup messages in de.alt.* that would never include a PGP key, that requires
a comment.
I would recommend against listing no.alt.*, nl-alt.*, and de.alt.* as unmanaged.
Hi Adam,
Now that I've glanced at control.ctl again, two other unmanaged >>>>hierarchies are listed:
it-alt.*
oesterreich.*
While looking at making the change in the web pages, I see we did not >>>speak about other alternative hierarchies.
I had simply noticed it-alt.* and oesterreich.* in rone's unified >>control.clt and your generated list. I don't have first hand knowledge.
You're one of the most knowledgeable about Usenet hierarchies, that's
why I asked. :)
Should no.alt.* and nl-alt.* also considered as "unmanaged" hierarchies? >>>They both have an associated PGP key but I do not know what is the
policy to create a newsgroup? Is it intended after any demand of
someone and a signed control article is then sent, or is there a >>>validation by a sort of Board?
I cannot guess what the policies are, but if the control messages
use a PGP key, even if there is some informality about adding a group to >>checkgroups, I'd call that "managed", given that the proponent would
never send the newgroup message himself. The keyholder has got to be >>considered to be the hierarchy manager for this purpose.
This has the advantage that there can be checkgroups issued regularly,
an impossibility in truly unmanaged hierarchies.
If there's a checkgroups, that provides satisfactory evidence of
hierarchy management. Similarly, a PGP key provides satisfactory
evidence of hierarchy management.
Agreed.
But if the proponent and not the hierarchy administrator issues newgroup >>messages in de.alt.* that would never include a PGP key, that requires
a comment.
I believe it is the case.
For instance, the last de.alt.comm.iphone+ipad+co created in 2012:
https://ftp.isc.org/pub/usenet/control/de/de.alt.comm.iphone+ipad+co.gz
Message-ID: ><newgroup-dac.iphone+ipad+co-20120518@thorongil.babylonsounds.com>
From: Simon Paquet <[snipped]>
Control: newgroup de.alt.comm.iphone+ipad+co
Newsgroups: de.alt.admin,de.alt.fan.ipod
Date: Fri, 18 May 2012 12:27:03 +0200
de.alt.comm.iphone+ipad+co is an unmoderated newsgroup, it has been
discussed in de.alt.admin and there was no significant protest.
Bitte richten Sie die unmoderierte Newsgroup de.alt.iphone+ipad+co ein.
Ueber die Einrichtung wurde in de.alt.admin diskutiert und es gab
keinen heftigen Protest.
For your newsgroups file:
de.alt.comm.iphone+ipad+co Apples mobile Geraete und ihre Software.
And afterwards, Thomas takes this newsgroup into account when sending >checkgroups for the de.* hierarchy.
And he also cleans up no longer used groups in de.alt.* when appropriate.
That's the sort of things we could mention in a revived "hierarchy
notes" file that I could display along with hierarchy information.
I would recommend against listing no.alt.*, nl-alt.*, and de.alt.* as >>unmanaged.
Noted. Thanks for your motivated reasons. I agree with you.
BTW, I've added it-alt.* and oesterreich.* in the list of unmanaged >hierarchies:
http://usenet.trigofacile.com/hierarchies/index.py?status=unmanaged
And afterwards, Thomas takes this newsgroup into account when sending
checkgroups for the de.* hierarchy.
And he also cleans up no longer used groups in de.alt.* when appropriate.
He won't list the group in the next checkgroups. I don't think I've
noticed that he issues rmgroups for defunct de.alt.* groups.
That's the sort of things we could mention in a revived "hierarchy
notes" file that I could display along with hierarchy information.
I appreciate your enthusiasm. That file might be edited every 20 years
or so, heh.
Hi Adam,
And afterwards, Thomas takes this newsgroup into account when sending >>>checkgroups for the de.* hierarchy.
And he also cleans up no longer used groups in de.alt.* when appropriate.
He won't list the group in the next checkgroups. I don't think I've
noticed that he issues rmgroups for defunct de.alt.* groups.
There are PGP-signed rmgroup control articles for the removals too.
Example with the last one removed:
https://ftp.isc.org/usenet/control/de/de.alt.rec.flugsimulation.gz
Control: rmgroup de.alt.rec.flugsimulation
Message-ID: ><rmgroup-de.alt.rec.flugsimulation-20220205@thangorodrim.ancalagon.de>
Date: Sat, 05 Feb 2022 21:29:34 -0000
But the From address (at thh.name) is not the one expected by the
control.ctl entry (at dana.de) so they were not processed by ftp.isc.org.
However, checkgroups for de.* are properly processed, and the de.alt.* >newsgroups are then removed at that time according to the ftp.isc.org rules.
. . .
He won't list the group in the next checkgroups. I don't think I've
noticed that he issues rmgroups for defunct de.alt.* groups.
But if the proponent and not the hierarchy administrator issues newgroup messages in de.alt.* that would never include a PGP key, that requires
a comment.
And what for de.alt.*? Shouldn't it be considered as "unmanaged"?
If I remember well, there's a possibility to create any newsgroup in
de.alt.* (its control.ctl entry has a doit for a newgroup control
article) and for the sake of not removing them with de.* PGP-signed checkgroups, they are included in de.* checkgroups.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 62:04:53 |
| Calls: | 6,654 |
| Files: | 12,200 |
| Messages: | 5,331,623 |