Lets create comp.microsoft.public.vc.mfc or alt.microsoft.public.vc.mfc
in [MFC]
|
Prev: Simple encryption solution
Next: MFC Dialog - Menu
From: Peter Olcott on 15 May 2010 13:38 "Hector Santos" <sant9442(a)gmail.com> wrote in message news:hsmkm9$17av$1(a)news.ett.com.ua... > Bert Hyman wrote: > >> In news:hsmip3$173v$1(a)news.ett.com.ua Hector Santos >> <sant9442(a)gmail.com> >> wrote: >>> You do realize that this is a "Network" of computers and >>> that there is >>> really a "backbone" concept and that really a "LIST" >>> that you are managing? >> >> The backbone died along with UUCP. > > > The transport method did, but not the "backbone" > distribution concept per se. > > These are still old guards that want to get paid. Try to > go get mail from giganews.com or from other major > providers for free. > > If you follow the path of any of these "free" peering > servers, including fee based ones, they all lead to a > pretty small set of "backbone" providers everyone feeds > off directly or indirectly. > > Here are some information: > > http://www.top1000.org/ > > When you have a topology where most of the servers peer > off the giganews.com and other top providers, we are > talking a still a star and backbone concept. > Giganews.com isn't going to peer off me or you. > > == > HLS So why does one individual have the authority to delete a whole hierarchy? If we restrict this authority will microsoft.public.* continue to live after Microsoft abandons support? If we migrate to other hierarchies can this fix the problem, or will anyone be able to delete this whole hierarchy too?
From: Hector Santos on 15 May 2010 13:55 Peter Olcott wrote: > He should not have this degree of authority. It should be as > difficult to delete a newsgroup as it is to create one. Peter, these were vendor sponsored areas. Not a pure open public discussion area that has no "ownership" per se. That is now how it worked FOREVER, whether it was the old FIDONET echos or its offshoot USENET where many of these old guards came from - FidoNet. It was really a matter of who had access to the highest bandwidth. It could of been they worked for the Feds, consultants or where part of academia which usually had access to free federal funded pipelines. The mass public (early ISPs) had to PAY and we, among others, sold hosting software to them to do that, PPP Servers, Mail Distribution software, etc so they sell to the Peter's and others using Dialup Networking etc. IOW, there were was always a "person" that issues controls and became the main "owner" per se of the group. It was a LIST that was passed around - literally and trust me, there is a directed path these nodes work off each other - then and still today. Someone maintains control of the list and if you wanted to be a dedicated friendly member node of the network, you followed the LIST - you didn't create your own competing LIST and if you did, it was to create your own little SUB-NET off a different list - but it was two list now - not one. Apparently according to the information provided by the individual in the link I provided, who is maintaining the "list" for microsoft, he indicated Microsoft did manage it themselves long ago (up to 2 years ago?) and when they stopped, this fellow took over. So when you think that you want to create an AREA, that effectively means that you are creating a list that you want OTHERS to carry as well. They need to basically get a copy of your list and add it to their setup. If you want to do this in a network of agreed membership, it can only work well off a common list - thats call usenet in this case. If you can also get a Fidonet echo list as well that the group of fidonet nodes carry. Here is a site where you can get a list of Fidonet Echos: http://www.filegate.net/echolist/ Now, the mindset of usenet is more open, fidonet LOVES administrator controls, but honestly, there is still really management to usenet a the basic level, someone has get all the feeds from everyone and pass it around to others, and yes, other pass to others, etc more than ever before because the hardware/speeds allow it, but it not as open, willy nilly as you people seem to believe - its NOT. -- HLS
From: Geoff on 15 May 2010 13:57 On Sat, 15 May 2010 12:17:58 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >Once nodes that honor control commands automatically (meaning by >people that don't sit at their servers deciding who to keep or not), >especially the main "backbone" ones, they will slowly be OFF the >network of nodes within "USENET." Most, if not all, Usenet servers have not automatically obeyed control messages since the cancelbot wars and the rm-group wars several years ago. The question will be whether the news admins of a particular server will approve the control messages deleting the microsoft.* hierarchy and how fast it will degrade. My guess is it won't degrade very much at all unless Microsoft begins writing C&D letters to Usenet admins. Even then I don't think Microsoft would have valid grounds. Yes, the propagation and carriage might be fragmented, but Usenet has never been "centralized" and I don't believe it needs a centralized server for a particular group or hierarchy to survive.
From: Hector Santos on 15 May 2010 14:11 Peter Olcott wrote: > So why does one individual have the authority to delete a > whole hierarchy? Its the old "he who owns the basketball, dictates the rules." If not him, who? Remember - think LIST (file). > If we restrict this authority will microsoft.public.* > continue to live after Microsoft abandons support? Anyone can create its own LIST and share it with others that connect to him if they AGREE with the sharing - in this case, YOU became of the create and owner and because others off you FOLLOW you, they might be using you as the the feed, they will follow your changes. > If we migrate to other hierarchies can this fix the problem, > or will anyone be able to delete this whole hierarchy too? Thats a philosophical and human idea and ONLY off nodes that honor your control messages - usually PEERS off a MAIN PEER. I personally do not like to hangout in anything but sponsored support areas. Thats like saying: "I setup a new server with a large bandwidth and I created a list that will be part of my LIST NEWSGROUPS response. They are a blend of usenet and private list, including a copy of the old microsoft.* for backward compatibility. The server is news.peterserver.com" In other words, telling everyone (most of the people off the msnews.microsoft.com) to connect to you now or any other of your friendly peers that want to help you offer additional servers the same LIST you offer. It becomes a selling point for most. Other "new breed" "open source, free mindset" "anonymous" people won't care where they can troll. Here is a tool you can download that allows you to grab a LIST from NTTP servers. Do it on so call usenet server and you will see that not all of them are the same. http://beta.winserver.com/public/files/getnewsgroups.zip with: Archive: getnewsgroups.zip Length Date Time Name ------ ---- ---- ---- 65536 05-11-10 23:38 GetNewsgroups.exe ------ ------- 65536 1 for help: GetNewsgroups /? example usage: GetNewsGroups msnews.microsoft.com GetNewsGroups news.ett.com.ua GetNewsGroups news.aioe.org A file *.newsgroup for will created for the host name provided. If you wanted to just see if one has microsoft.public.*, GetNewsGroups {host} /out:{host}.newsgroups /hier:microsoft.public.* -- HLS
From: Hector Santos on 15 May 2010 14:35
Usually, the higher you are up the chain, the more you follow your uplink service offerings if only to offer a closer mirroring of services offered. That is what I mean by "centralization" its not a pure star, but the Giganews.com is a LARGE star in this network as one the primary sources MOST others peer off. Some peers offer all of it, some offer maybe text only, etc. Honestly, it is very simple. Let suppose right now you wanted to become a FEED. What will you do? You will setup and UPLINK and a DOWNLINK and for most, they are the same. They don't have to be, but the smaller you are and off the main chain, that is usually all you need. But you don't have to and the redundancy built into the software allows for distributed data exchange. For example, I can (re)set up server to feed off my main T1 ISP to pull USENET. That would be 1 HOSTING ENTRY into my setup. I can also setup a 2nd hosting entry for msnews.microsoft.com specifically only for the microsoft.public.* groups. The software automatically handles it. but I can tell it only to sent to microsoft the new local postings on my system. Don't send it to my ISP hosting record. I could, if I didn't care the duplicity and overhead it will create for other software to trap the dupes. But that is how the peer to peer meshing is working today. Its a controlled managed dedicated path that is defined BY the operator and you really don't want the overhead in redundancy but you still have to check for it because it is an anarchy network once you get off the main "backbone." In other words, off giganews.com and the like who have a DEEP CONTROL of who peers off them. -- HLS Geoff wrote: > On Sat, 15 May 2010 12:17:58 -0400, Hector Santos > <sant9442(a)nospam.gmail.com> wrote: > >> Once nodes that honor control commands automatically (meaning by >> people that don't sit at their servers deciding who to keep or not), >> especially the main "backbone" ones, they will slowly be OFF the >> network of nodes within "USENET." > > Most, if not all, Usenet servers have not automatically obeyed control > messages since the cancelbot wars and the rm-group wars several years > ago. The question will be whether the news admins of a particular > server will approve the control messages deleting the microsoft.* > hierarchy and how fast it will degrade. My guess is it won't degrade > very much at all unless Microsoft begins writing C&D letters to Usenet > admins. Even then I don't think Microsoft would have valid grounds. > > Yes, the propagation and carriage might be fragmented, but Usenet has > never been "centralized" and I don't believe it needs a centralized > server for a particular group or hierarchy to survive. |