text:
Talk:Inanna

Connection with Athena and requested semi-protection
Athena was also identified with Inanna in that scholars wrote that Athena's birth from the head of her father was likely inspired by Athena's return from the underworld. This was sourced but kept on being removed by an IP. Thus I have filed a request at WP:RFPP. Thanks. 2407:7000:A2AB:D00:85B6:FA4B:2C3A:8482 (talk) 09:55, 8 May 2020 (UTC)

Semi-protected edit request on 8 May 2020
Basically a reversion of the disruptive IP's edits: change to Thanks. 47.72.38.134 (talk) 22:13, 8 May 2020 (UTC)
 * Red question icon with gradient background.svg Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. — Tartan357   ( Talk ) 15:43, 10 May 2020 (UTC)

Requested move 18 August 2020

 * The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: No consensus. After several listing periods, there is no agreement as to whether to move to the proposed name or retain the current one, and both are valid. Hence we simply retain the status quo. — Amakuru (talk) 16:04, 20 September 2020 (UTC)

Inanna → Ishtar - Ishtar was merged here because Ishtar and Inanna are clearly the same deity, but Ishtar is clearly the most prevailing name. This can be seen through Google Ngram (link), where Ishtar has consistently seen more use than Inanna since the 1800s. Ishtar being more prevailing is also reflected on Google Scholar (which gives Inanna 19,900 hits and Ishtar 30,300 hits). Inanna is the deity's original Sumerian name but Ishtar is more prevailing, both in academia and elsewhere. Unless Ishtar be made a separate article again (as it was until 2018), the article title, as per Wikipedia naming policy, should be Ishtar. Ichthyovenator (talk) 21:22, 18 August 2020 (UTC) —Relisting. BD2412  T 18:59, 27 August 2020 (UTC)  —Relisting. —usernamekiran (talk) 04:39, 4 September 2020 (UTC)

 * Support move. The common name for this deity is Ishtar.  O.N.R.  (talk) 19:58, 19 August 2020 (UTC)
 * Oppose in favour of Inanna-Ishtar. This is two separate theologies frequently merged in academic study.  One should not eclipse the other.  The joint name, used in some publications, is better than the prior two articles.  --SmokeyJoe (talk) 06:19, 22 August 2020 (UTC)
 * "Ishtar and Inanna are clearly the same deity" seems to imply that the writer believes in deities. Inanna is a concept of the older culture, and Ishtar is a concept of the later culture.  --SmokeyJoe (talk) 11:23, 22 August 2020 (UTC)
 * "Inanna-Ishtar" doesn't work. There are no ancient sources that speak of "Inanna-Ishtar"; they all either call her "Inanna" or call her "Ishtar." Likewise, modern scholarly sources generally don't use a hyphenated name. I'm not even sure why I used a hyphenated name in this article, since Pryke 2017 generally uses "Inanna/Ishtar," rather than "Inanna-Ishtar." —Katolophyromai (talk) 15:57, 22 August 2020 (UTC)
 * Not sure how "Ishtar and Inanna are clearly the same deity" implies that I believe in either. Ishtar is clearly a later incarnation of the deity the Sumerians worshipped as Ishtar and is treated as such in academia. The move discussion ongoing right now is not whether they are the same or not (the article as of now treats them as such), but what the article should be called. As I showed in the nomination, Ishtar is used more commonly than Inanna and I suspect that either singular term is used more often than Inanna-Ishtar or Inanna/Ishtar. Which term is more correct is not relevant; Ishtar does eclipse Inanna as a name and Wikipedia should follow suit. Ichthyovenator (talk) 16:23, 22 August 2020 (UTC)

 * If not renames to the joint name, and having the article compare and contrast the similar deity from completely different periods, the article should be de-merged. In fact, I am leaning to that as the first preference.  There are different sets of references for each. --SmokeyJoe (talk) 11:28, 6 September 2020 (UTC)
 * Oppose -- Ishtar was originally a Semitic deity assimilated to Inanna in many ways. Inanna was not really assimilated to Ishtar, so that would be the tail wagging the dog.  I would really favor two articles again (this discussion actually reveals a problem with merging them). AnonMoos (talk) 10:03, 22 August 2020 (UTC)
 * I strongly disagree with the view that there should be two separate articles. Although Inanna and Ishtar were originally separate, they are so closely identified from such an early date that it is impossible to say anything about either goddess that isn't directly relevant to the other. A separate article about Ishtar would have to include all the same material that is included in the article about Inanna and vice versa. In the scholarly sources, Inanna and Ishtar are generally treated as one deity. The only sensible option here is to have a single article. —Katolophyromai (talk) 15:57, 22 August 2020 (UTC)
 * I do not feel strongly in regards to whether the article should be split or not, but I do agree with that they typically are treated as one in academia and that it significantly decreases unnecessary overlap to just have one article. Whether the article should be split is really a separate discussion; what I'm saying is that if we maintain a single article, the title should be Ishtar, since it is more frequently used and (I would argue) more recognizable. Ichthyovenator (talk) 16:23, 22 August 2020 (UTC)

 * Neutral At this point, I don't have an especially strong opinion about whether the article should be titled "Inanna" or "Ishtar," as long as it is maintained as a single article. Both names are in widespread use. —Katolophyromai (talk) 15:57, 22 August 2020 (UTC)

 * Ichthyovenator & Katolophyromai -- "Ishtar" was a not too detailed figure in the Semitic pantheon into whose name the specific characteristics of Inanna were poured (parallel to how many of the deities of the Roman pantheon were somewhat vague and shadowy until they were identified with Greek gods and all their associated mythology), so to me having a single article under the name "Ishtar" would be a rather strange outcome -- and if the article merger facilitated this undesirable outcome, then it was the wrong thing to do. AnonMoos (talk) 20:43, 22 August 2020 (UTC)
 * The important thing is not whether Ishtar and Inanna should be regarded as separate figures, but if they currently are regarded as such. From my understanding current scholarship treats them as early and late versions of the same deity. If we are to have one article for both, I believe the article title should be Ishtar since it is more widely used than Inanna. Ichthyovenator (talk) 11:53, 29 August 2020 (UTC)

 * Friendly oppose Inanna nearly existed for a thousand years as a Sumerian (non-Semitic) goddess before the Semitic Ishtar appeared, and Ishtar actually adopted many of the traits of Inanna, so if any should have primacy, it should be Inanna. Ishtar may have more presence in publications, but that would only be because we have more information on the more recent dynasties and their cults. I would favour two separate articles, as for Heracles and Hercules, but if only one article is to remain it should be about Inanna first and foremost, and only about Ishtar as a later evolution. पाटलिपुत्र  Pat   (talk) 18:40, 29 August 2020 (UTC)
 * As I've stated above; I do not feel strongly about whether the article should be split or not. The important aspect to consider in that respect is whether academia treats Ishtar and Inanna as separate or the same. If the articles are split, there is no problem in regards to the article title but I am not sure reliable sources support it being split (but please provide evidence that they do if that's the case). If the article is not split, the title should be Ishtar because that name is more frequently used and recognizable than Inanna. What name is more correct or original does not matter. The article on the most famous Babylonian king is titled Nebuchadnezzar II, not the original Nabû-kudurri-uṣur or the more correct Nebuchadrezzar, because that variant of the name dominates in scholarship and popular usage. Ichthyovenator (talk) 22:33, 29 August 2020 (UTC)
 * I don't think this is a case of numerous name variants for a single person or deity (in which case your "frequency" argument would stand), but rather a case of two deities with different names, the second one (Ishtar) adopting the characteristics of the first one (Inanna) later in history ("Inanna and Ishtar were originally separate, unrelated deities..." with refs in article). In this case, the "frequency" argument is irrelevant. Ideally, we should have two articles, but if only one article is used, Inanna should have primacy, Ishtar being a later development. Best regards पाटलिपुत्र  Pat   (talk) 19:36, 30 August 2020 (UTC)
 * You are not wrong, but my concern is not whether Ishtar and Inanna are separate deities but whether they are considered as such in academia today; Wikipedia follows reliable sources. The Roman Empire and the Byzantine Empire were not separate empires, but there are different articles on them because modern scholarship treats Roman and Byzantine studies as distinct topics. Does modern scholarship treat Ishtar and Inanna as different deities? If it does, I 100 % agree with you that the article should be split (as has been done on the Ancient History Encyclopedia: 1, 2). If it doesn't, the title of the article should be Ishtar (as has been done on Encyclopedia Britannica: link) per WP:COMMONNAME. I don't think Ishtar being later matters in regards to which name is more recognizable. Ichthyovenator (talk) 21:45, 31 August 2020 (UTC)

 * Support Ishtar is used more often than Inanna in modern sources, and so this should be the article's name. The various names of the goddess should be explained in the bofy of the article, not its title. Dimadick (talk) 18:55, 3 September 2020 (UTC)
 * Support Inanna (Ishtar) per infobox title. Best of both worlds. Randy Kryn (talk) 12:10, 4 September 2020 (UTC)
 * I specifically oppose that title suggestion. On Wikipedia, parentheticals are used in titles as a form of disambiguation, not as a dual title name. Dual title names are occasionally done with a slash, but it is generally discouraged. Rreagan007 (talk) 19:44, 4 September 2020 (UTC)

 * Weak Oppose This is a very long article, and it is about equally divided in content between early Inanna and later Ishtar. Certainly imposing Ishtar backwards would be anachronistic, so at least in the text, the first half should firmly remain Inanna.  Which means that in an article titled "Ishtar" the reader would have to scroll half-way down before they get the actual mentions of Ishtar. That doesn't seem right or intuitive to me. Splitting into two articles would solve part of the problem, but it doesn't seem ideal either (although it wouldn't be terrible - we see separate articles for Zeus & Jupiter, Aphrodite & Venus, etc.).  I don't think there's any happy solution here. Walrasiad (talk) 22:18, 5 September 2020 (UTC)
 * Support Per WP:COMMONNAME. Majority of sources I've worked with use the variant Ishtar. --HistoryofIran (talk) 23:54, 8 September 2020 (UTC)

 * The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

A Commons file used on this page or its Wikidata item has been nominated for deletion
The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for deletion: Participate in the deletion discussion at the nomination page. —Community Tech bot (talk) 16:41, 18 December 2020 (UTC)
 * Myths and legends of Babylonia and Assyria (1916) (14801964123).jpg

Removal of dubious Greek equivalence
As far as I am aware, the infoboxes are meant to document attested syncretism. Penglasse doubtlessly had credible info about Greek and Roman deities so his iddentification of equivalents of Ishtar/Inanna isn't what's called into question here, though. The problem was the addition of Persephone. When it comes to the other Near Eastern equivalents, the evidence comes from primary sources, discussed in this article in some capacity: Pinikir is outright referred to as (an) "Ishtar" in the "Babili" (eg. written in Akkadian) rituals from Hattusa; Ashtart and Ishara are equated with Ishtar in a trilingual (Akkadian-Ugaritic-Hurrian) god list from Ugarit; Shaushka's name was written logographically as "ISHTAR" and she was called "Ishtar of Subartu" in Mesopotamia and plays Ishtar's role in the Hurrian translation of Epic of Gilgamesh according to renowned Hittitologist Gary Beckman. All of them share functions too though there is no full overlap (Shaushka and Ashtart had no pronounced astral character, for instance). In contrast, the comparisons to Persephone are rooted in dubious comparative speculation based on modern ideas about one myth, and here were sourced from the book of a controversial author who is not a mythology specialist, and not an Assyriologist either, and as such hardly an authority (the fact his information in the article is outdated or otherwise blatantly wrong doesn't help his case). It therefore shouldn't be present here at all. If anything Nergal has a stronger claim to being called the Mesopotamian Persephone, one could argue: married to a much less commonly worshiped underworld deity, stuck in the underworld through marriage in a late tradition, etc.HaniwaEnthusiast (talk) 14:03, 12 August 2021 (UTC)

 * Nobody cares. There is no rule that says sources must be Assyriologists or that they have to agree with your own opinions. Skyerise (talk) 14:07, 12 August 2021 (UTC)

 * Also, you seem to be unaware that the growing seasons in Greece and ancient Mesopotamia differ. In Greece, the growing seasons are spring, summer, fall; winter is the fallow season because it is too cold. In Mesopotamia, the growing seasons are fall, winter, spring; summer is the fallow season because it is too hot. Both are myths about the fallow season; to say they are not the same because winter =/= summer is ignorant, even if an "expert" Assyriologist shouts it from their ivory tower. Haven't you ever gardened? Skyerise (talk) 14:32, 12 August 2021 (UTC)

 * Also, you wrote in an edit comment "attested syncretism, which is what the infobox is meant to document as far as I am aware" - that's simply not true. It's for equivalences, whether of ancient synccretism or not. Both modern scholarship and modern popular mythology are perfectly valid equivalences and there is no reason not to include them in the infobox with a citation, so the reader can draw their own conclusions. You seem to be under the mistaken impression that Wikipedia is supposed to form some "right" conclusion and exclude others. That's simply not the case and you'll get along better with other editors if you drop the attitude. Skyerise (talk) 15:07, 12 August 2021 (UTC)

 * Really, no one should consider themselves an expert on ancient mythology unless they have also studied both Astronomy and Agriculture! Skyerise (talk) 15:28, 12 August 2021 (UTC)

 * While you were busy bitching about sources, perhaps you neglected to check the credentials of John M. Riddle, who is Alumni Distinguished Professor emeritus of History at North Carolina State University, where he holds appointments in the history and botany departments. So your bogus claims about his dubious reputation are a bit ridiculous, Professor. Perhaps you mixed him up with some other Dr. Riddle? And the book was reviewed by Mark J. Plotkin, Ph. D., President of the Amazon Conservation Team, "The book is pure Riddle: extraordinary history and blinding insight with a touch of whimsy. Recommended only for those interested in plants, war, altered states, witches, and sex - in other words, everyone!" So not only are you long-winded, what you claim can't be trusted. Any response to that ? And try to keep it conversational, I'm not interested in your page long lectures. Don't you know how to talk to people? Skyerise (talk) 00:11, 21 August 2021 (UTC)

Seeing User:Skyerise bully and threaten User:HaniwaEnthusiast here and on their talk page gives me very little confidence in this page's point of view. -Apocheir (talk) 22:55, 24 October 2021 (UTC)

Alright, against my better judgement I'm going to try to mediate this. With regards to the Riddle reference, much more weight is being put on it than it can support. The reference is to a single page in Riddle's book: possibly the reference was meant to extend to further pages? Riddle is drawing comparisons between Inanna and Persephone to support his idea about the use of pomegranates as a contraceptive in classical times. He's a historian of medicine, not of mythology or religion: granted they were closely related at the time, but the book is about medicine foremost. Based on, I think calling him controversial is fair.

I recommend removing the Riddle reference and referencing substantial, mythology-focused material instead. If this is a real equivalence, there must be something else out there that supports it. -Apocheir (talk) 22:44, 25 October 2021 (UTC)

 * Of course there are other sources. I've added two. And I think Riddle should be left until WP:RSN says otherwise. But it's up to the editor who thinks it's not reliable to open a thread there... The additional references show that Riddle's not out in lala-land like HW would like to imply. Skyerise (talk) 23:08, 25 October 2021 (UTC)

I haven't really been following this discussion and I don't spend much time on Wikipedia anymore, but I definitely do not think that John M. Riddle should be cited as a source about Inanna. Firstly, he is not a specialist in ancient Mesopotamia, ancient Near Eastern studies, religion, mythology, or anything else that might be directly relevant to Inanna in any way. Secondly, as others have already pointed out, even much of his work in his area of specialization (i.e., ancient medicine) is extremely dubious. I actually wrote a post on my blog nearly two years ago about how he is primarily responsible for promoting the fantasy that the Greeks and Romans primarily used silphium as a contraceptive, that it was genuinely highly effective, and that they overharvested it to extinction (all three parts of which are probably wrong).

I also don't think there should be any comparisons to Persephone in the lede. The lede should be reserved only for the most important material and, in my opinion, the only connection to Greek mythology that is well established enough and widely mentioned in the scholarly literature to warrant mention in the lede is the connection to Aphrodite through Astarte. —Katolophyromai (talk) 12:20, 26 October 2021 (UTC)

 * I agree that moving the Persephone part later is the right thing to do. I am a little concerned about the Mark 2011 reference. It looks like the author is also a co-founder of the World History Encyclopedia website, so the editorial independence is a bit questionable. Nothing in the article jumps out at me as being blatantly wrong, but I'm no expert on this subject. Would like someone else's opinion. -Apocheir (talk) 00:09, 28 October 2021 (UTC)
 * Since nobody else seemed to jump to the task, I moved Persephone later.
 * Except for one paragraph about his opinion on the meaning of the descent myth in, anything that cited Mark 2011 also cited a few other things. Calling him a "philosopher" is a stretch: "freelance writer and adjunct professor of writing" is more accurate based on what information I could find on him. Plus, imho the opinion wasn't that interesting. I went ahead and removed that paragraph and the two other references to it.
 * The same author is that of Mark 2017 and 2018. Mark 2017 (on Anu) is only used in one place, and it seems that it would be easy to find another reference that supports the same point, possibly among the references of Mark 2017. Mark 2018 (on Gilgamesh) is referenced 6 times and might be harder to replace, if it actually needs replacing. -Apocheir (talk) 00:10, 2 November 2021 (UTC)

Inanna and the Venus cycle
I don't see anything in the article about the connection of the descent of Inanna with the period that Venus is not visible during its retrograde cycle. That's seven days before the inferior conjunction and seven days after it. I'll see if I can find some sources for this, but it's well known among some... Skyerise (talk) 15:27, 12 August 2021 (UTC)

Missing reference(s)
Deacy 2008 is cited but not listed. I'll add more here as I find them. Skyerise (talk) 21:09, 12 August 2021 (UTC)

Gressman & Obermann 1928 - same. Skyerise (talk) 21:15, 12 August 2021 (UTC)

 * All uses were supported by two or more citation so I removed these. Skyerise (talk) 13:28, 21 August 2021 (UTC)

Undue emphasis on the Parpolas
I noticed that, for some reason, there is now a full, three-paragraph section devoted solely to the views of Asko and Simo Parpola titled "Fringe theories." It is, however, my understanding that the Parpolas' views are very fringe within Assyriology and they don't seem to be especially influential on the perception of Inanna by the general public. (The fringe theories of the anti-Catholic conspiracy theorist Alexander Hislop and the ancient astronaut theorist Zecharia Sitchin are far more influential on the general public than anything either of the Parpolas has written, but I don't think it would be appropriate to devote them much attention here.)

Neither of the Parpolas was even mentioned in this article when it passed GA review and, when I last left it, if I remember correctly, it only contained one sentence mentioning each one. Much of the material about the Parpolas seems to be devoted to a general critique of their work that isn't directly relevant to Inanna. It seems clear to me that this extensive focus on the Parpolas violates WP:UNDUE. I propose that one of the following solutions be applied to the section about the Parpolas: 1) it be removed completely, 2) it be radically pared down to just a single paragraph and re-integrated into the section "In antiquity," or 3) it be broken up, moved to the articles about the Parpolas respectively, and edited to suit those articles. —Katolophyromai (talk) 13:08, 26 October 2021 (UTC)

 * I'd be happy with any one of those solutions. Skyerise (talk) 17:51, 26 October 2021 (UTC)
 * Ok, I boldly removed the extended discussion of the Parpolas' views with this edit. As I say in my edit summary, much of the material is encyclopedic, but doesn't really belong in a general article about Inanna. It may be better suited in the articles about the Parpolas themselves. —Katolophyromai (talk) 21:31, 26 October 2021 (UTC)

Later Influence Cleanup
This excerpt « 1}} Gary Beckman, a researcher of religions of ancient Near East, calls neopagan authors "not revivalists, but inventors," and notes that they often incorrectly "view all historically attested female divinities as full or partial manifestations of a single figure," and highlights that while Ishtar did overshadow many other deities, she was never a "single Goddess." » is impertinent and degrades the value of the article.

This excerpt deserves removal.

For somereason Vpab15 continues to vandalize and harass the good faith removal of this impertinent excerpt.

Please someone with the power and authority to look into this, do so. Thank you! 67.8.169.171 (talk) 12:50, 4 February 2023 (UTC)

 * I know nothing about this Beckman person, but it seems that in a number of cases scholars of ancient religions aren't necessarily too impressed by neo-pagans. It's not confined to Inanna... AnonMoos (talk) 15:20, 4 February 2023 (UTC)
 * hence the raison for removal. thank you to all! 67.8.169.171 (talk) 20:14, 4 February 2023 (UTC)

 * "that they often incorrectly "view all historically attested female divinities as full or partial manifestations of a single figure" True enough, when talking about the Triple Goddess. "Some neopagans believe that the Triple Goddess is an archetypal figure which appears in a number of different cultures throughout human history, and that many individual goddesses can be interpreted as Triple Goddesses. The wide acceptance of an archetype theory has led to neopagans adopting the images and names of culturally divergent deities for ritual purposes" . Dimadick (talk) 15:25, 6 February 2023 (UTC)
 * agreeable, so can we get some addition of Triple Goddess in here for context because the bias in Beckman's excerpt devalues impartiality and is imbalancing the article in my opinion. thank you 67.8.169.171 (talk) 03:18, 7 February 2023 (UTC)

Outdated?
We have a pretty bombastic declaration of "obsolete theories" here, in a very old and debated field. No such claims can be made based on a single author.

 * Some researchers in the past attempted to connect Ishtar to the minor goddess Ashratu, the Babylonian reflection of West Semitic Athirat (Asherah), associated with Amurru, but as demonstrated by Steve A. Wiggins this theory was baseless, as the sole piece of evidence that they were ever conflated or even just confused with each other was the fact Ishtar and Ashratu shared an epithet – however the same epithet was also applied to Marduk, Ninurta, Nergal, and Suen, and no further evidence can be found in sources such as god lists. There is also no evidence that Athtart (Ashtart), the Ugaritic cognate of Ishtar, was ever confused or conflated with Athirat by the Amorites.

If Wiggins declaration of "outdatedness" has any merit, surely some other scholars should refer to his great feat.- Berig (talk) 16:12, 26 September 2023 (UTC)

title: Talk:Inanna


text: Category:Antipsychiatry

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Category:Antipsychiatry


text:
Empire City

Empire City may refer to:

Places in the United States

 * Empire City (California), a historic landmark in Empire, California
 * Empire City, Kansas, an unincorporated community
 * Empire City, Nevada, a former town site absorbed by Carson City
 * Empire City, Oklahoma, a town
 * Empire City, Oregon (1853), former county seat of Coos County, Oregon and, since 1965, the Empire district of the city of Coos Bay, Oregon
 * Empire City, a nickname for New York City
 * Empire City, a nickname for Glen Falls, New York

Fictional entities

 * Empire City (comics), a fictional place in the DC Universe
 * Empire City, a fictional city that is home to Courageous Cat and Minute Mouse
 * Empire City, New Mexico, a fictional city in the video game Gun
 * Empire City, the fictional city in which the video game inFAMOUS is set
 * Empire City, a fictional city featured in the animated series COPS
 * Empire City, a fictional city featured in the animated series Steven Universe
 * Empire City, the fictional city setting for Superhero Movie

Literature

 * The Empire City, a 1959 novel by Paul Goodman
 * Empire City, a 2020 novel by Matt Gallagher

Video games

 * Empire City, an extra track of the EA game Need For Speed III: Hot Pursuit
 * Empire City, a level in the Sonic the Hedgehog game Sonic Unleashed
 * Empire City: 1931, a video game by Seibu Kaihatsu

Other uses

 * MV Empire City, a British merchantman sunk by U-198 during World War II
 * Yonkers Raceway & Empire City Casino, a New York Thoroughbred horse racing facility opened in 1899 that became Yonkers Raceway and expanded to include Empire City Casino

title: Empire City


text:
Talk:Memory segmentation

Paging, segmentation, and protection
Afaik, paging isn't another way to ensure page protection; in fact, I believed that segmentation was built upon paging just to address a lack of the latter.

See for example Tanenbaum A., "Modern Operating Systems", 2nd edition, §4.8 - fig. 4.37.

 * No. There exist processors that offer segmentation without paging (e.g., the Burroughs large systems) and thus offer only segment-level protection, processors that offer paging without segmentation (e.g., several RISC processors such as MIPS processors) and that use protection bits in the page table to provide protection, and processors that offer both paging and segmentation and either use only segment protections or segment protections and per-page protections to provide protection. Guy Harris 04:12, 13 November 2007 (UTC)

Merge?
I believe this article should be merged with Memory segment. They are about essentially the same thing. Strake 21:29, 9 August 2006 (UTC)

Agreed, or maybe memory segment should be merged here. I wrote most of the memory segment article because at the time, that seemed like the logical place. But here might make sense. Propose the merge David.kaplan 02:14, 22 October 2006 (UTC)

 * Currently, memory segment is an article about segmentation in x86 processors, not about segmentation in general. This page shouldn't be merged with it; we need at least one page to describe segmentation in general, without incorporating a bunch of x86 stuff that might lead people to think x86 segmentation (whether real or protected mode) is the be-all and end-all of segmentation.  (Perhaps memory segment should be renamed in such a way as to make it clearer that it's x86-specific.) Guy Harris 04:06, 13 November 2007 (UTC)

 * Looking for the meaning of the order or command ls I found that it is defined elsewhere as "short for list" and in Wikipedia as: "Its name derives from a similar command list segments in Multics, a system in which memory segments and files were synonyms." So I wonder if the origin is "list segments" and not the improbable "list". Could someone please confirm whether ls actually originates in "list segments"? I am after this because it is so much simple to remember the commands if one knows where they come from originally. Because of this I think that memory segment is a concept clearly different from segmentation and should be explained separately. --FelipeTD (talk) 19:30, 12 July 2009 (UTC)

 * Memory segment now redirects to memory segmentation, and there's an x86 memory segmentation page for all the x86-specific stuff. Guy Harris (talk) 07:55, 18 November 2010 (UTC)

Segmentation and protection
It's worth noting that in several implementations of segmented VM, "protection" (when present at all) was not applied to the segment but rather the segment pointer. On both the Burroughs and IBM S/38 systems authorities were checked when the segment pointer was loaded. I vaguely recall that in the Burroughs case some of the protections were loaded into hardware registers, for later checking against memory accesses, but in the case of the S/38 no authority information was preserved after loading the pointer -- rather the reason for loading the pointer (read/write/execute/etc) was checked against the authority bits in the pointer, and an error generated if the pointer could not be loaded for that reason.

In spite of this "weakness", the S/38 OS was quite secure. drh (talk) 22:35, 3 January 2013 (UTC)

Confusion about memory address segments and linker's segments may not exist
The article’s title "memory segmentation" suggest that it is a matter of memory addressing. But such things as [ "code segment"] (in an object file) do not require that segment registers actually had any use. Incnis Mrsi (talk) 20:16, 28 January 2013 (UTC)
 * Sounds right to me, maybe some of the discussion of object files should be deleted or moved. Segments (or groups) in an object can support memory segmentation if it exists. Peter Flass (talk) 20:31, 28 January 2013 (UTC)
 * But what to do with /? In one hand, the term possesses the same ambiguity between linker’s segments and CPU segments. In another hand, the information at CS: usually originates from ".text", so the "code segment" (CPU) usually implies "text segments" (linker). BTW, I just noticed that these things are referred to as sections (not segments) in objdump’s documentation. Incnis Mrsi (talk) 21:10, 28 January 2013 (UTC)

I did move the "object file" segment discussion to that article. Peter Flass (talk) 15:01, 8 February 2014 (UTC)

x86 segmentation
Hint: On x86 CPUs within the "real mode" we becomes exactly 1088 KiB - 15 Bytes addressable space together with the combination of the segment and the offset part for to build an address. — Preceding unsigned comment added by 85.177.153.121 (talk) 08:42, 13 February 2014 (UTC)

A toxic mix of misunderstanding and misconception
The first line of the article defines the segmentation as "the division of a computer's primary memory into segments or sections", and then mixes the segmentation of physical memory and segmentation of virtual memory, although these are not the same thing, and thus should not be confused.

Continuing with the first paragraph:

 * In a computer system using segmentation, a reference to a memory location includes a value that identifies a segment and an offset within that segment. Segments or sections are also used in object files of compiled programs when they are linked together into a program image and when the image is loaded into memory.
 * This part is indeed talking about dividing "computer's primary memory into segments", and is actually referring to the segment:offset addressing scheme introduced with Intel's 8086 machines, which used 20-bit physical (linear) address obtained by shifting a 16-bit segment register 4 bit to left and adding a 16-bit offset register. It was a way to expand the addressable primary memory space (only to 20-bit though) without combining two registers linearly and obtaining a 32-bit address space.

Continuing with the second paragraph:

 * Segments usually correspond to natural divisions of a program such as individual routines or data tables so segmentation is generally more visible to the programmer than paging alone.[1] Different segments may be created for different program modules, or for different classes of memory usage such as code and data segments. Certain segments may be shared between programs.[1]
 * This part is, like the rest of the article, talking about dividing the virtual address space of a process into logical segments, as the major advantage is that it allows flexible loading of a process by allowing the loading of different segments separately in both time and space domains, and also allows sharing of segments among processes.

What does \\//ikipedia say about this?

 * From the article "real mode":

 * Real mode, also called real address mode, is an operating mode of all x86-compatible CPUs. Real mode is characterized by a 20-bit segmented memory address space (giving exactly 1 MiB of addressable memory) and unlimited direct software access to all addressable memory, I/O addresses and peripheral hardware. Real mode provides no support for memory protection, multitasking, or code privilege levels.

 * From the article "segmentation fault" (that's a good article):

 * The term "segmentation" has various uses in computing; in the context of "segmentation fault", a term used since the 1950s, it refers to the address space of a program.[citation needed] With memory protection, only the program's own address space is readable, and of this, only the stack and the read-write portion of the data segment of a program are writable, while read-only data and the code segment are not writable. Thus attempting to read outside of the program's address space, or writing to a read-only segment of the address space, results in a segmentation fault, hence the name.

 * This should not be confused with memory segmentation (segmentation of the computer's address space, not an individual program's address space), which is a historical term for the approach to memory management nowadays known as paging.[2] The corresponding fault in this context is a "page fault", which has a different meaning. However, these are related in that an invalid page fault generally leads to a segmentation fault, and segmentation faults and page faults are both faults raised by the virtual memory management system. Segmentation faults can also occur independently of page faults: illegal access to a valid page is a segmentation fault, but not an invalid page fault, and segmentation faults can occur in the middle of a page (hence no page fault), for example in a buffer overflow that stays within a page but illegally overwrites memory.

The article should emphasize that the term "memory segmentation" applies to;
 * segmentation of physical memory space of a computer (related to segment:offset addressing scheme used in real mode), which is considered at the hardware level (MMU), not the kernel level (where multi-process management is handled).
 * segmentation of virtual memory space of running processes (related to and can be mixed with paging), which is considered at the kernel level, where each process has a virtual address space, and each process is given a "segment table" and a "page table" assuming both segmentation and paging are used by the kernel.

85.110.13.232 (talk) 19:44, 29 May 2015 (UTC)

 * OK.

 * ~6000 characters: Article

 * ~2700 characters + ~1800 characters (for excerpts from other articles): Original comment in the talk page pointing out the need for improvement, and (of course) tipping off segmentation fault needs some too!

 * ~7500 characters: First reply in the talk page

 * One doesn't need to be a statistician; one is or isn't.

 * If we have a system in which operands aren't directly referred to by addresses in physical memory, we can have all processes running in the same address space (that does not imply a lack of memory protection - you might, for example, have capability-based addressing) or we can have processes running in separate address spaces. That distinction is independent of how addresses are mapped to physical memory.

 * An operand might be mapped to a physical memory address in a number of ways:

 * The operand might be part of a segment, with a segment descriptor, possibly with an offset from the beginning of the segment, if there's more than one operand per segment. The segment descriptor includes the physical address of the beginning of the segment, and the offset within that segment is added to that physical address to give the physical address of the operand.  The segment descriptor might also have a "presence bit", with the reference faulting if the "presence bit" isn't set, and might also have a segment length, with the reference faulting if the offset within the segment goes past the end of the segment.  There might also be permission bits in the segment, with the reference faulting if the permission (read, write, execute) isn't granted.

 * The operand might be specified by an address. The upper bits of the address would be used to look in a page table (in memory or in registers) to find the physical address of the page containing the beginning of the operand, with the remaining bits added to the physical address of the page.  The page table entries might have presence bits, with the reference faulting if any page table entry accessed has the presence bit not set, and permission bits, with the reference faulting if any page table entry accessed doesn't grant permission for the access.  A page table entry might even have a length, with the reference faulting if the offset within the page going past the end of the page.

 * The operand might be part of a segment, with a segment descriptor, possibly with an offset from the beginning of the segment, if there's more than one operand per segment. The segment descriptor includes the physical address of a page table for the segment, and the offset within that segment is used to look in that page table to find the physical address of the page in the segment containing the beginning of the operand, with the remaining bits added to the physical address of the page.  The comments for both of the previous schemes apply here.

 * The operand might be part of a segment, with a segment descriptor, possibly with an offset from the beginning of the segment, if there's more than one operand per segment. The segment descriptor includes the "logical" address of the beginning of the segment, and the offset within that segment added to that "logical" address to give the "logical" address of the operand.  The comments about the first scheme given above apply here.  The "logical" address is then used to look in a page table to find the physical address of the page containing the beginning of the operand.  The comments about the second scheme given above apply here.

 * I've generally seen the first scheme referred to as "segmentation", the second scheme referred to as "paging", and the third scheme referred to as "segmentation plus paging". The fourth scheme is called IA-32 :-); the only CPUs I know of that implement it are IA-32 CPUs.

 * The first scheme is implemented on the B5000 and B5500, the Intel 80286, and the original HP 3000 series; there may be others. The third scheme is implemented on the GE 645 and its successors, and possibly other systems (I think a segment containing an array could be paged on later Burroughs mainframes).  The second scheme is implemented on a lot of machines.  The fourth scheme, as noted, is, as far as I know, unique to IA-32.

 * The way the segment descriptor, in the schemes that include segment descriptors, is found differs from machine to machine. An address might consist of a segment number combined with an offset-within segment, with the segment number used as an index into a table of segment descriptors; that's the most common scheme.  (As I remember, in the original PDP-10, the 18-bit address space was split, so that the lower 128K words could be thought of as one segment and the upper 128K words thought of as another segment, with the "segment descriptors" being base-and-bounds registers.) In the Burroughs machines descriptors could sometimes be treated as in-memory objects by regular code; they were protected by tag bits.  In the 80286, and in IA-32 processors, special instructions would load segment descriptors into segment registers, with most memory reference instructions specifying an offset within the segment; the segment register to be used is either implied by the type of reference or explicitly indicated by a prefix.

 * The schemes with segment descriptors are what has historically been referred to as "segmentation". See, for example, Chapter 16, "Segmentation", in Operating Systems: Three Easy Pieces, by Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau, and some of the older references in that chapter.  That is what the first paragraph is referring to; it's not just talking about x86 real-mode segmentation.

 * (By the way, the book by the Arpaci-Duesseaus says, in a side note on page 4 of chapter 16, "The term segmentation fault or violation arises from a memory access on a segmented machine to an illegal address.. Humorously, the term persists, even on machines with no support for segmentation.")

 * All of this is "virtual" memory in the sense of "operands aren't directly referred to by their physical addresses". The "real mode" scheme on x86 is a relocation scheme, so it's only weakly a form of "virtual" memory; there are no segment descriptors - the segment number is, in effect, the physical address of the beginning of the segment, rather than being an index in a table of entries giving (among other things) the physical or logical addresses of the beginning of segments. There are no presence bits, so you can't take a "segment not present" or "page not present" fault.

 * The PDP-11, which is the system on which the UNIX system Lions was describing, implemented the second scheme; its address space wasn't segmented, in the sense of there being segment descriptors. It was, instead, divided into 8 4096-byte pages (that's the term DEC used in, for example, the PDP-11/45 Handbook). The page table was located in a bank of special registers. Each page had a pair of registers, one giving the physical address of the beginning of the page and one giving the length of the page (and, yes, references past the length of the page caused a fault), the protection of the page, and an indication of whether the length was the length from the beginning of the page or the end of the page.

 * So any notion of "segmentation" was provided by the OS, not the hardware. UNIX, on the PDP-11, didn't actually do any form of paging; a process could either be "swapped in", with the entire address space resident in memory.

 * So there's:

 * "segmentation at the hardware level", which can - and, with the exception of x86 real mode, generally does - involve translating operand addresses to physical memory addresses, and is thus more than just segmentation of physical memory;
 * "segmentation at the OS level", which might be implemented using "segmentation at the hardware level" or might not.

 * (BTW, thanks for tipping me off to the fact that segmentation fault needs some work.) Guy Harris (talk) 17:27, 30 May 2015 (UTC)

 * I may (or may not) have written this "Segments usually correspond to natural divisions of a program such as individual routines or data tables so segmentation is generally more visible to the programmer than paging alone.[1] Different segments may be created for different program modules, or for different classes of memory usage such as code and data segments. Certain segments may be shared between programs."

 * i tend to try to forget about the x86 b@$tard version of segmentation, which is covered by another article anyhow. This was written with consideration of B5500 segmentation, where each ALGOL procedure or COBOL paragraph would be a segment. Data was also segmented somehow, although I'm not clear on how, perhaps each array or structure was a segment.  Multics made each external PL/I proceure a segment (unless the linker was uesd, a later option).  Data was usually grouped into the linkage segment, but there was a technique to create a segment containing all the data for a procedure (CDS). Peter Flass (talk) 21:14, 30 May 2015 (UTC)

 * You wrote "Segments usually represent natural divisions of a program such as individual routines or data tables so segmentation is generally more visible to the programmer."

 * in this edit.

 * User:Vadmium added "Different segments may be created for different program modules, or for different classes of memory usage such as code and data segments. Certain segments may even be shared between programs."

 * in this edit; that text was later joined with your sentence when your sentence was moved. (You changed "represent" to "correspond to" in this edit.)

 * I'm not sure how the 5xxx, or B6xxx and successors, handled descriptors. From my quick attempts at reading the manuals, it's not as simple as "addresses have a segment ID and offset, and segment IDs are indices into a segment descriptor table"; I think descriptors can be handed around as data items, but are protected by tagging.  I have the impression that arrays are segments, which can be paged in later versions of the system.  My quick reading gave me the impression that stacks aren't explicitly represented by descriptors, but have a base and bounds, and are thus similar to segments.

 * Multics also, of course, let you map arbitrary named-in-the-file-system segments into the process's address space (that's the only way to access the file's data; that mapping is also how executables, linkage segments, data segments, etc. are mapped in).

 * x86 segmentation has three flavors:

 * real mode "segmentation", which is mainly a trick to extend the physical address space and kinda sorta provide some relocation capabilities;
 * 80286 protected mode segmentation, which is real segmentation, with segment registers containing segment descriptors rather than just the physical base address of the segment, and with the instructions to load and store segment registers using a segment ID, rather than the raw contents of the segmentation register, as the operand (load looks up the segment in the descriptor table, store stores the segment ID which is also stored in the segment register), and no paging is supported;
 * IA-32 protected mode segmentation, which is real segmentation, but the segments don't have physical addresses, they have "linear" addresses, which existing within a 4GB paged "linear" address space (so segments don't have page tables, and a segment must either be mapped into the linear address space in its entirety or not mapped into the linear address space at all, even though not all of its pages are necessarily resident in physical memory). Guy Harris (talk) 22:50, 30 May 2015 (UTC)

 * Address space: The set of addressable physical or logical memory cells.
 * Physical address space: The set of addressable physical memory cells (e.g. for 4 GiB of installed primary memory on a byte addressed machine, physical address space comprises 2^32 elements).
 * Virtual address space: The set of addressable logical memory cells.
 * Multi-tasking: Multiple processes can be advancing concurrently (not necessarily in parallel), on the same physical address space, over a given period of time.
 * Address space of a process: The set of addresses that can be the value of a pointer in the source code of the process. In multi-tasking systems, the address space of a process is a virtual (or logical) address space, regardless of the relative sizes and the mapping between the process' address space and the physical address space, because concurrently running processes cannot occupy the same physical memory space, although they can share a part of it.

 * You write:
 * "If we have a system in which operands aren't directly referred to by addresses in physical memory, we can have all processes running in the same address space (...) or we can have processes running in separate address spaces".

 * Somebody else writes:
 * "If we have a system in which operands (or operators) are directly referred to by addresses in physical memory, we can still have all processes running in the same address space or we can have processes running in separate address spaces".

 * And, how do these two should look/sound/feel/compile together? When we are talking about memory, it is always virtual (or logical) vs. physical (or real); regardless of whether we are referring to data (operand) or instruction (operator), and regardless of whether data and instructions reside in the same physical memory (as in harvard vs. von Neumann), we are talking about memory addressing. I'd say trying to improve the article whose talk page we are populating right now (and which needs improvement) is at least an equally good alternative to trying to improve other articles (we're tipped off about).

 * The last edit to segmentation fault replaced an important part which emphasized that a segmentation fault is an access violation to logical segments of a compiler emitted file format. The edit was made with an edit summary stating "Remove completely wrong material, and try to state things more correctly. This could still use work. (Please look at the Multics system and at several other systems before jumping in". In fact, a bag of other newer operating systems than multics should be checked before jumping in. Anybody who has an interest on archaic operating systems, particularly multics, can check out The Multics Virtual Memory: Concepts and Design. It will remain in the pages (not segments) of the long lost past. The memory is still segmented, however modern operating systems (not talking about multics here) only use one segment and set all segment registers to the same value, and when a program receives a segmentation fault, it comes from the paging unit since the program referred to an invalid page, in its own virtual address space, as a program cannot refer to an address outside its own virtual address space, in which it is allowed to work by the operating system. As stated in Memory Translation and Segmentation, "the classic “Segmentation fault” Unix error message is not due to x86-style segments, but rather invalid memory addresses normally detected by the paging unit". The anatomy of a program in memory, that many programmers are used to, and which is composed of (logical) segments for kernel space, stack, mapped files, heap, bss, data, text, and un-allocated (free and thus non-addressable) memory are logical segments, not physical. From Tanenbaum's modern operating systems (3rd ed. p.234): "We emphasize that a segment is a logical entity, which the programmer is aware of and uses as a logical entity. A segment might contain a procedure, or an array, or a stack, or a collection of scalar variables, but usually it does not contain a mixture of different types". The last edit to segmentation fault removed the a piece in the article that was (I think) aimed to bridge the gap between logical segments of a PE/ELF/COFF/etc. executable file structure emitted by a language compiler (kernel space, stack, mapped files, heap, bss, data, text, un-allocated) and the concept of physical segments (i.e. contiguous segments in the physical primary memory) that can be used by an operating system to isolate processes by giving each process a separate segment.

 * Primary purpose of memory segmentation is protection, i.e. to prevent a process from jumping out of its own virtual address space into other processes' virtual address spaces. In real mode, there is no notion of memory protection or privilege, as there is no notion of multi-tasking, and thus it shouldn't be called virtual memory, in a weak form or in whatever form.
 * When there isn't a multi-tasking kernel/OS running, the concept of "memory segmentation",  if present, is merely an addressing scheme provided by a hardware/firmware such as MMU/BIOS, used to address physical memory segments, which you referred to as "segmentation at the hardware level".
 * And, when there is a multi-tasking kernel/OS running, the concept of "memory segmentation",  is present, and is a protection scheme provided by the kernel/OS, used to address virtual (logical) memory segments, which you referred to as "segmentation at the OS level".
 * By the way, I'd rather you referred to these in the article, not in your talk page post; explicitly stating these distinctions is, in my opinion, very much required to dispel "misunderstandings and misconceptions", hence the "original" post, up there somewhere.You're welcome for tipping you off to the fact that memory segmentation needs some work. And the rest is filling an article's talk page with twice as many (and probably more) characters as the article has, where the article does need improvements much more than the talk page indeed. Unfortunately, this is something quite common for EECS articles.

 * 85.110.54.215 (talk) 14:40, 1 June 2015 (UTC)

Note that there are multi-tasking, protected, OSes single address space operating systems in which the address space of process A is the same address space as the address space of process B is the same address space as the address space of process C is the same address space as the address space of every other process on the system, so one should be careful when speaking of processes and address spaces.

My edit removed the claim that

 * This should not be confused with memory segmentation (segmentation of the computer's address space, not an individual program's address space), which is a historical term for the approach to memory management nowadays known as paging.

In Multics, the address space was segmented using segmentation hardware; paging was also used (the contents of a segment were paged), but it was most definitely not the case that the address space was divided into protected segments by breaking a single linear address space into regions, with holes between them, and treating all "page not present" faults in the holes as errors. It's irrelevant that Multics is now a historical OS; present-day OSes might not happen to use what segmentation hardware the processors on which they run, if any, to isolate regions of the address space, but Wikipedia's purpose is not to explain to computer users how Windows, various Unix-like OSes, and some other OSes such as z/OS work, it's to explain concepts. (And Multics wasn't unique there; for example, the Burroughs large systems and BiiN systems also had both segmentation and, in the later Burroughs systems and BiiN systems, paging.)

So segmentation at the hardware level - which, in most processors, provides protection - can be used to implement segmentation at the OS level. It can even be done so on systems that provide both segmentation and paging. Segmentation at the OS level can also be done on a system with only paging support in the MMU. That does not mean that "memory segmentation .. is a historical term for the approach to memory management nowadays known as paging".

Ignoring the fact that individual programs might not have separate address spaces, I assume that "segmentation of the computer's address space" really means "segmentation at the hardware level" and "segmentation of ... an individual program's address space" means "code is running in an address space with multiple regions possibly separated from each other" (although two of those sorts of segments could be contiguous, in which case an attempt to refer past the end of the first segment could, rather than being treated as an error and getting a fault, be interpreted as an attempt to refer to the beginning of the second segment; in many, if not all, systems with segmentation in hardware, segment+offset addresses were usually used or constructed in fashions such that if you went past the end of one segment that wasn't interpreted as referring to the beginning of another segment - the best you can do with only paging hardware is to put space between the segments and treat page faults in that space as errors).

So "segmentation of the computer's address space", i.e. "segmentation at the hardware level", is segmentation, not paging, and is, therefore, most definitely not "nowadays known as paging". (Given that some systems did both segmentation and paging, it couldn't possibly be "known as paging".) "Segmentation of ... an individual program's address space" could be done either with segmentation at the hardware level, if the hardware supports it, or paging.

As for where the "segmentation fault" term came from, well, as I said earlier, Chapter 16, "Segmentation" of the Arpaci-Dusseaus' "Operating Systems: Three Easy Pieces" says the term comes from segmented machines (i.e., machines that do segmentation at the hardware level), but persists on systems that don't do segmentation at the hardware level.

So the segmentation fault article must not make the false claim that "memory segmentation .. is a historical term for the approach to memory management nowadays known as paging". It should, perhaps, note that segmentation at the OS level might be implemented with paging, and is so implemented in current operating systems, but that's it.

"Primary purpose of memory segmentation is protection, i.e. to prevent a process from jumping out of its own virtual address space into other processes' virtual address spaces. " Yes, the primary purpose of segmentation is protection; however, not all OSes put processes in individual virtual address spaces - you might have a single address space operating system and use capabilities for protection (and, no, capability hardware is not just an old dead historical idea), and it's also used to prevent a process from jumping outside the bounds of its own objects.

"When there isn't a multi-tasking kernel/OS running, the concept of "memory segmentation",  if present, is merely an addressing scheme provided by a hardware/firmware such as MMU/BIOS, used to address physical memory segments, which you referred to as "segmentation at the hardware level"." No, "segmentation at the hardware level" is whatever form of segmentation is done by hardware. That segmentation performs, at minimum, relocation; it might also perform bounds checking, as is the case on the 80286, IA-32 processors, the GE 645 and its successors, the Burroughs B5000 and successors, the BiiN processors, etc.. (And multi-tasking OSes, such as 8086/8088 versions of UNIX, existed that didn't provide address spaces protected from each other.)

"And, when there is a multi-tasking kernel/OS running, the concept of "memory segmentation",  is present, and is a protection scheme provided by the kernel/OS, used to address virtual (logical) memory segments, which you referred to as "segmentation at the OS level"." (We'll leave aside here the fact that a multi-tasking OS might not even provide memory protection, as noted in the previous paragraph.) Such an OS could:

 * run all processes in a single address space, and rely on mechanisms other than separate address spaces to provide protection - possibly, for example, providing an address space consisting of multiple segments, with a process being unable to construct descriptors for segments (except in the kernel), and only being able to address segments to which it already has a descriptor (meaning those descriptors are capabilities);
 * run all processes in their own address spaces, with the address space starting at a given virtual address and ending at another given virtual address space, so that there's only one "segment" within the address space (think of the PDP-6 Monitor, i.e. the pre-PDP-10 version of TOPS-10);
 * run all processes in their own address spaces, with the address space divided into multiple segments - that could be done with segmentation hardware, i.e. "segmentation at the hardware level", or with paging and laying out the address space in multiple regions.

As for long discussions in talk pages, if you don't have fundamental disagreements, maybe you can have short pages. However, you started out with ~4600 characters, much of which I found seemed to misunderstand some of the concepts here or to have some recentism (as in "thinking of x86 segmentation rather than segmentation as used on other systems"), and I needed to dispel some of the misunderstandings. So we do have some fundamental disagreements (including, perhaps, disagreement whether Wikipedia should tell people how systems work now or educate them about all the ways a system could work and the ways they did work in the past - and could possibly work in the future; I'm extremely firmly in the latter camp), and there's going to have to be a fair bit of discussion (unless you're willing to just let me edit this article and segmentation fault as I deem fit). Guy Harris (talk) 18:37, 1 June 2015 (UTC)

 * BTW, Gustavo Duarte's "Memory Translation and Segmentation" essay should probably be called "x86 Memory Translation and Segmentation"; as he states in the first paragraph, "This post is the first in a series about memory and protection in Intel-compatible (x86) computers", so it doesn't discuss memory translation and segmentation in general, it just discusses how x86 processors happen to implement them. Don't use it to discuss the notion of a segmentation fault in general; those faults can be generated by the segmentation part of the memory management unit - that's what happened on System V/286, for example (obviously, System V/286 didn't do paging, as the 80286 didn't do paging).

 * Wow! long discussion. It's useful, but getting hard to follow.  I'll only add a few comments.

Peter Flass (talk) 19:38, 1 June 2015 (UTC)
 * I agree that 286 and 386 protected mode provides "real" segmentation; 8086/88 doesn't and shouldn't be covered in a lot of detail here, although it's worth mentioning.
 * "segmentation of ... an individual program's address space" might be exemplified by MVS, where a program's address space can contain multiple "memory subpools" with different protection and access rights.
 * "Primary purpose of memory segmentation is protection," I'm not sure it's the primary purpose, but it's certainly an important purpose.
 * "disagreement whether Wikipedia should tell people how systems work now or educate them about all the ways a system could work and the ways they did work in the past - and could possibly work in the future; I'm extremely firmly in the latter camp)" Agreed.
 * Can someone summarize suggested changes to the article in a couple of paragraphs?

 * About all I'd do is somehow distinguish "dividing an address space into regions" from "segmentation in the MMU", clearly indicating that the former can be implemented using the latter but doesn't have to be implemented using the latter. I have the introduction more clearly indicate that this page refers not to just "dividing an address space into regions" but to doing so by doing more than just having more than one contiguous region, i.e. treating segments as first-class objects in the hardware.  I think the "x86 architecture" section adequately deals with x86's peculiarities and the limitations of real-mode segmentation.  Perhaps the general notion of "dividing an address space into regions" deserves a separate page, but I'm not inclined to think so. Guy Harris (talk) 20:58, 1 June 2015 (UTC)

 * I think the bare-minimum requirement of a public encyclopedia entry on "memory segmentation" can be stated, in plain thinking, as follows: A lot of people are programming and getting memory segmentation errors along the way, and many of them haven't been playing with computers since 70s. Understanding of the memory layout of a running program is crucial. Therefore, the article should emphasize the relationship between segments in an executable/linkable file format (as emitted by a compiler) and the segments of the physical memory on which that file is loaded and running (as managed by the operating system and hardware), i.e. "which segments are we talking about, and when?", and make sure a reader would have answers regarding modern systems, on which s/he is getting segmentation faults, before history. Otherwise, I put stock in facts anyway, not camps. 85.110.59.236 (talk) 22:20, 1 June 2015 (UTC)

 * What you want is not an encyclopedia article, it's a lesson in a programming class. Feel free to write, on your own Web site, a programming tutorial that explains to the horde of people writing code and getting segmentation errors, but don't try to turn this article into into "Avoiding Illegal Memory References For Dummies".  Wikipedia is not a howto.  (If a lot of people are programming and getting memory segmentation errors along the way, we need better programming environments that make it easier to write correct code and harder to write incorrect code.)  It's not the job of "Depression (economics)" to tell people what not to do in a modern economy to avoid it going into a depression or to get it out of a depression, and it's not the job of "Memory segmentation" - or "Segmentation fault" - to tell people how to avoid segmentation faults or fix their code when it gets one.

 * So, yes, we have a fundamental disagreement, and the chances that you'll convince me that your point of view is correct are so close to zero as to be well approximated by zero. Guy Harris (talk) 23:41, 1 June 2015 (UTC)

 * Wanting to convince somebody who is admittedly inconvincible and yet still choses to argue requires a significant faith in that person's dishonesty and/or a powerful desire to waste time: I have no intention what so ever to waste anybody's time (including mine), and I sure do hope that you're not that dishonest about your state of mind (although, as I said, I put stock in facts, not camps). So, I neither want nor need to convince you, and frankly I think nobody should want or need it when somebody admits there is zero chance that s/he'll be convinced. Luckily, in a project edited by the "public", it doesn't matter much if a single person is convinced by a suggestion or not. If you find yourself not convinced by a suggestion in a talk page and explicitly stating that there is zero chance that you'll be convinced, feel free to step aside and let others have their opinions on the suggestion too, as you already have yours, although I wouldn't venture to comment on how healthy an opinion whose chance to be changed is zero is; I can just hope that's a lousy approximation than the truth.

 * However, I have to say that wild speculations in the above paragraph kind of made me question the intentions within the discussion:
 * (1) Nobody suggested writing such a thing as tutorial/howto, not implicitly and not explicitly. You need to relax about blaming others. Such a strange speculation to come up with though. The above paragraph just emphasized that segmentation fault is quite common in software development cycle, and therefore the relationship between logical memory segments (within COFF, or ELF, or PE, or the old a.out formats) and physical memory segments (within physical memory) is worth noting. Although I have to add, taking any discussion onto fuzzy borders of politics is waste of everybody's time, e.g. "oh my god, look at dd (unix), somebody is writing a howto on backup and restore of MBR, hold it! wikipedia is not a howto". These kind of actions prohibit improvements to wikipedia. dd (unix), and many^many other wikipedia articles, are doing quite alright with their sub-sections providing examples, as long as they are not interpreted as howtos. A simple paragraph or two that aims to bridge the gap between logical memory segments and physical memory segments could hardly look like a "howto example" anyway.

 * (2) The simple suggestion that was made above is, in exact words (unfortunately only ~3800 characters apart), memory segmentation should emphasize the relationship between segments in an executable/linkable file format (as emitted by a compiler) and the segments of the physical memory on which that file is loaded and running (as managed by the operating system and hardware). And, unfortunately, the wild speculations are that this would transform the article from an encyclopedia article into a programming lesson ("lesson in a programming class"), or a howto, or probably some book titled "Avoiding Illegal Memory References For Dummies".

 * So, why memory segmentation should at least explain, briefly (now that we know the discussion is open to speculations), the relationship between logical memory segments and physical memory segments? Well because there are logical memory segments and physical memory segments, and their relationship goes a little beyond name resemblance, that's why. As stated in Code segment: "In computing, a code segment, also known as a text segment or simply as text, is a portion of an object file or the corresponding section of the program's virtual address space that contains executable instructions". Since they are both "memory segments", memory segmentation would do better if it at least provided a brief explanation (not a book-long, or howto style, or any other speculative style, but a wikipedia style explanation; we do explain things here too, don't we?), without neglecting more commonly used systems, how logical memory segments correspond to physical memory segments: The whole suggestion, and this discussion (not to be judged by the historical content), is about this simple phrase, in exact words or as interpreted (without deriving speculations from the suggestion phrase).
 * 85.110.74.250 (talk) 18:21, 2 June 2015 (UTC)

 * I've pointed you to factual information about segmentation in various computers, current and historical, and you've either disregarded it or chose to treat it as unimportant as it's not relevant to present-day programmers getting segmentation violations. This article should be about the general concept of segmentation, not about its manifestation in present-day operating systems, in order to be encyclopedic.  I have not seen any indication that you would ever be convinced of that, so further discussion here seems pointless. Guy Harris (talk) 19:23, 2 June 2015 (UTC)

This article reads as if segmentation is a feature. Obviously it was written in retrospective with an intel x86 OS programmer mindset. S. is not a feature or option but a severe limitation. Paging and virtual memory are something entirely unrelated. S. is the consequence from the disparity between how many bits it takes to represent a western alphabet character (5-8) and how many bit it takes to address a memory worth using (min 20-24). When transistors (and memory) are expensive one can simply not afford to work with 32 bit addresses. Until the 90's the price/cost of a PC did not allow for a full 24 or 32 bit architecture. "Primary purpose of memory segmentation is protection"; is complete nonsense. That is a byproduct of a specific and smart implementation. --Moritzgedig (talk) 09:12, 30 December 2019 (UTC)

 * On the contrary:

 * This article makes a distinction between the segmentation found in some non-x86 systems with the segmentation in 16-bit and 32-bit mode on x86 processors, so it's hardly "written in retrospective with an intel x86 OS programmer mindset".
 * It's a limitation, on non-x86 systems, in that segment sizes are limited - for example, the maximum segment size on the GE 645 and Honeywell 6180 was 218 36-bit words, or 220 9-bit bytes, so Multics had to have the notion of "multi-segment files".
 * It has nothing whatsoever to do with the disparity between the size of a character and the size of memory - where does that notion come from?
 * Segmentation existed long before personal computers, so "Until the 90's the price/cost of a PC did not allow for a full 24 or 32 bit architecture." is irrelevant.

 * And protection is a significant purpose of segmentation, even if it isn't the primary purpose, in the non-x86 systems discussed. Guy Harris (talk) 20:07, 30 December 2019 (UTC)

External links modified (January 2018)
Hello fellow Wikipedians,

I have just modified one external link on Memory segmentation. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20111013222125/http://www.bitsavers.org/pdf/intel/iAPX_432/171821-001_Introduction_to_the_iAPX_432_Architecture_Aug81.pdf to http://www.bitsavers.org/pdf/intel/iAPX_432/171821-001_Introduction_to_the_iAPX_432_Architecture_Aug81.pdf

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 15:47, 25 January 2018 (UTC)

 * It moved (bitsavers.org moved manuals about chips into a separate "components" collection). Guy Harris (talk) 18:50, 25 January 2018 (UTC)

Incomplete history in the lead
The lead currently states Segmentation was originally invented as a method by which system software could isolate software processes (tasks) and data they are using. It was intended to increase reliability of the systems running multiple processes simultaneously. However, on the B5000, the Master Control Program (MCP) also used segmentation to manage memory; a process could run even when some of its segments were swapped out.

Given that there is a History section, I'm not sure that this even belongs in the lead. I'm not sure whether to remove the paragraph, delete it, or merge it into History. Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:27, 7 August 2022 (UTC)

Short description?
Edit https://en.wikipedia.org/w/index.php?title=Memory_segmentation&curid=1323131&diff=1126677852&oldid=1112702082 by Widefox added the short description. That description is too general, since it applies to architectures where the OS is not free to move segments. How about ? Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:23, 11 December 2022 (UTC)
 * Feel free to change it to what you like. Per WP:SDCONTENT ...short descriptions are not intended to define the subject of the article, but rather to distinguish it from other similarly named articles in search results... . Widefox ; talk 15:51, 11 December 2022 (UTC)

India Education Program course assignment
This article was the subject of an educational assignment at Department of Electronics and Telecommunication, College of Engineering, Pune, India supported by Wikipedia Ambassadors through the India Education Program during the 2011 Q3 term. Further details are available on the course page.

The above message was substituted from by PrimeBOT (talk) on 19:59, 1 February 2023 (UTC)

Examples?
#Examples currently has #S/370 architecture and #x86 architecture; I believe that Burroughs MCP on the B5000 and B6500 would be better examples. All virtual operating systems on the IBM System/370 rely on paging and make minimal use of segmentation. Similarly, while some systems exploited segmentation on the Intel 80286, I'm not aware of any that exploited it on subsequent chips.

I'm not sure whether it would be better to replace the current examples or simply add new ones. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:24, 3 January 2024 (UTC)
 * The GE 645/Honeywell 6180 + Multics might also be a good example as well; it's a more "typical" implementation of segmentation than the Burroughs machines are, so both would be interesting. Guy Harris (talk) 06:39, 24 January 2024 (UTC)

title: Talk:Memory segmentation


text:
Geoff Pevere

Geoff Pevere (born October 1957) is a Canadian lecturer, author, broadcaster, teacher, arts and media critic, currently the program director of the Rendezvous With Madness Film Festival in Toronto. He is a former film critic, book columnist and cultural journalist for the Toronto Star, where he worked from 1998 to 2011. His writing has appeared in several newspapers, magazines and arts journals, and he has worked as a broadcaster for both radio and television. He has lectured widely on cultural and media topics, and taught courses at several Canadian universities and colleges. In 2012, he contributed weekly pop culture columns to CBC Radio Syndication, which were heard in nearly twenty markets across Canada. He has also been a movie columnist and regular freelance contributor with The Globe and Mail.

Early life
Born in Ottawa, Ontario, Pevere grew up in a variety of locations including London and St. Catharines. He graduated in 1982 from the film studies program at Carleton University, where he was also a writer for the student newspaper The Charlatan and a contributor to CKCU-FM. He was subsequently a film reviewer for the city's CHEZ-FM.

In 1986 he was named the first program coordinator of the Toronto International Film Festival's Perspective Canada program, which introduced the work of Atom Egoyan, Bruce McDonald and Guy Maddin, among others, during his tenure.

Broadcasting
From 1986 to 1988 he contributed to CBC Radio's State of the Arts program, and in 1988 started a twelve-year stint as the movie reviewer on CTV's Canada AM.

From 1989 to 1993, Pevere hosted Prime Time, a groundbreaking nightly pop culture magazine series on CBC Radio. In 1993, after the death of Jay Scott, he was the host of Film International on TVOntario.

From 2003 to 2008 he was the co-host, with Richard Crouse, of Rogers Television's Reel to Real.

Writing
He co-wrote the book Mondo Canuck (1996), a bestselling critical evaluation of Canadian pop culture. He is also the author of Team Spirit: A Field Guide to Roots Culture (1998), Toronto on Film (2009) and Donald Shebib's Goin' Down the Road (2012). In 2014, he published Gods of the Hammer: The Teenage Head Story, a history of the influential Canadian punk rock band Teenage Head, for Coach House Books.

In 2012, he launched a network of encyclopedic critical pop cultural websites called "The Blessed Diversions Network". "Mean Justice" is devoted to western movies and TV shows; "The Big Shadow" is dedicated to the movie and TV culture of crime; "Riff Free or Die" covers the visual history of rock music; and "The Directory of Intemperate Enthusiasms" covers cult movies and TV.

Rendezvous with Madness
November 2015 saw Pevere's first stint as program director of the Rendezvous With Madness Film Festival, an annual event dedicated to showcasing the best in current cinema addressing issues of mental health, addiction and recovery.

title: Geoff Pevere


text:
Wikipedia:Peer review/Panama Canal/archive1

Panama Canal
This article is a Featured article candidates, and a very important waterway and technological acheivement. If anyone has any ideas or critiques please post. If you have any concerns or critiques please address them, or edit. Raskolnikov The Penguin 00:01, 2005 July 20 (UTC)
 * First of all, you need to remove it from FAC. Secondly the picture of the map is copyrighted. I'm pretty sure it's easy to find a public domain map of the panama canal, note that most government-created images are public domain.Borisblue 01:47, 20 July 2005 (UTC)
 * Since I had just taken the time to type all this up on the FAC page before it was deleted, I wanted to rewrite the info here in case it could benefit anyone: For everyone's info, I recently came back from Panama and took WAY TOO MANY PICTURES of the Panama canal and placed them in the Commons. Most of them were so similar that I only bothered to put the ones I liked the most.  You may want to take a look at them in case they are useful to the article.  Especially the pictures Image:Ship passing through Panama Canal 02.jpg and Image:Ship passing through Panama Canal 01.jpg may be useful, even though there is already a picture of the Miraflores locks.  There is no picture of the little trains that guide the boats though, as in Image:Trains guiding boats at Panama Canal.jpg.  If slightly different shots are needed, I can see what I can find if you leave a message on my talk page. On other critiques, couldn't there be more on the French attempt at the canal (especially with the panama scandals article being as small as it is), on the exacerbation of the disease problem during construction when they believed the disease to be spread by rats and dug water-filled trenches around all the beds which only increased the mosquito population, and on the economic impact of the canal on the country currently?  Some of it may be unncessary, but these are just suggestions. -Dozenist  talk  03:12, 20 July 2005 (UTC)


text:
Mike Chioda

Michael Joseph Canzano (born August 1, 1966) is a retired American professional wrestling senior referee, who most recently worked for World Wrestling Entertainment (WWE). Before his release on April 15, 2020, Chioda was the longest-tenured referee in WWE history, having been with the company for over three decades.

World Wrestling Federation / Entertainment WWF/WWE (1989–2020)
As a young adult, Chioda lived close to the Marellas (Gorilla Monsoon and his son Joey), who helped him break into the wrestling business. Being trained as a referee, Chioda first began to appear in WWE in 1989, when it was known as the World Wrestling Federation (WWF), most notably at Survivor Series 1989. After taking a hiatus from refereeing following WrestleMania VII, he began to reappear on camera around 1992.

He refereed the match where The 1-2-3 Kid (on that night he was simply known as "The Kid") as a jobber scored a huge upset over Razor Ramon. In May 1996 Chioda was involved in a controversial ending of a WWF Championship match at In Your House 8: Beware of Dog, during the match between Shawn Michaels and the British Bulldog, referee for the match Earl Hebner got injured and knocked out of the ring during the match and Chioda came to the ring as a replacement, when Michaels performed a German suplex, Chioda counted Michaels's shoulders down and awarded the match to the Bulldog, but at the same time Chioda counted Michael's down, Hebner came back in the ring and counted Bulldog's shoulders down and awarded the match to Shawn Michaels, then (on-screen) President Gorilla Monsoon came to ring and declared the match a draw. On January 18, 1998, at Royal Rumble, Chioda was the referee for the Intercontinental Championship match between Ken Shamrock and The Rock. During a match, Chioda was distracted by The Rock's team Nation of Domination when The Rock's teammate D'Lo Brown's foot gets stuck with the ropes, before The Rock used a brass knuckles to hit Shamrock and then disposed of the knuckleduster inside Shamrock's trunks behind of his back. By the time, Chioda looked back to the ring, he could only make a two count and Shamrock pulled off a belly to belly suplex slam, winning the match. However, as Shamrock celebrated, Rock appealed to him who, upon discovering the foreign object, reversed the decision and took the belt from a bemused Shamrock. Chioda gave it back to The Rock, making him the winner via disqualification. A furious Shamrock attacked him for stripping him of the title. On July 3, 1999, on Shotgun, Chioda got an Implant DDT from Gangrel following his loss against Test which Chioda officiated.

Chioda has also competed in an actual wrestling match, teaming with Chris Jericho and The Rock to take on the team of The Dudley Boyz and referee Nick Patrick on an episode of SmackDown! in 2001. Chioda actually scored the pinfall victory after delivering his version of "The People's Elbow" to Nick Patrick.

During the WWF tenure, he officiated matches such as Shawn Michaels vs. Steve Austin at WrestleMania XIV, Triple H vs. Vince McMahon at Armageddon 1999, and The Rock vs. Hulk Hogan at WrestleMania X8.

Following the September 11 attacks, Chioda began to wear an American flag patch on his referee shirt.

During the WWE Brand Extension, Chioda was sent to SmackDown! to become senior referee of that show. On an "All Referee" edition of the WWE.com show Byte This! in 2004, he told an inquiring Josh Mathews that he did not like the old-style "button-up and bow-tie" referee attire, preferring, at the time, the SmackDown! variant of referee shirt.

During his tenure on SmackDown!, he officiated a WWE Championship match between Big Show and Brock Lesnar in which Lesnar performed a superplex on Big Show and the ring collapsed. Chioda would rule the match a no contest.

In 2003, he was traded to Raw. Following the firing of Raw's senior referee Earl Hebner in 2005, Chioda was appointed as Raw's head referee.

At WrestleMania 23, he refereed the WWE Championship match between John Cena and Shawn Michaels, but was taken out after being hit with Sweet Chin Music by Michaels.

During his time as Raw brand head referee he would officiate Raw matches such as Triple H vs. Batista at WrestleMania 21, John Cena vs. Triple H at WrestleMania 22, Cena vs. Shawn Michaels at WrestleMania 23 and Cena vs Batista at SummerSlam 2008, WrestleMania XXVI, Extreme Rules 2010, and Over the Limit 2010 (Batista's last match in WWE before he quit for the first time). He also appeared in an episode of WWE Tough Enough's second season.

In November 2008, referees were made no longer exclusive to certain brands. Chioda refereed his first match on SmackDown in three years on November 28, 2008, when he refereed the Beat The Clock Match between Shelton Benjamin and Triple H; during the match, Chioda was knocked down and the match ended in controversy when it was decided that Jeff Hardy and Triple H finished their matches in the same amount of time. To settle this, the WWE Championship Match at Armageddon 2008 was made a Triple Threat Match.

At the pay-per-view event WWE Over The Limit 2011, The Miz initially defeated John Cena after a cell phone recording of Cena's voice saying "I Quit" was played into the microphone, although when the referee Mike Chioda heard it, he immediately reversed the decision and ordered the match to restart. This led to Cena defeating The Miz and retaining the WWE Championship. On August 15, 2011, Chioda was suspended for 30 days due to his first violation of the WWE's Talent Wellness Program.

On April 1, 2012, Chioda refereed the main event match of WrestleMania XXVIII between John Cena and The Rock. Chioda was featured as the referee in the 2012 iOS game, WWE Wrestlefest.

He refereed the main event of WrestleMania 31 between Brock Lesnar and Roman Reigns, turning the scheduled singles match into a triple threat match midway through after Seth Rollins cashed in his Money in the Bank contract mid-match, in which he won the WWE World Heavyweight Championship. The next year at Money in the Bank 2016, Chioda was the referee for the matches on the night when all three members of The Shield were WWE World Heavyweight Champion. Chioda refereed the WWE World Championship match between Dean Ambrose and A.J. Styles at Backlash.

On April 15, 2020, WWE announced that Chioda had been released from his WWE contract after 31 years with the company.

Retirement
On July 31, 2022, Chioda would referee the main event at Ric Flair's Last Match between Ric Flair and Andrade El Idolo against Jay Lethal and Jeff Jarrett. The day before the match took place, Chioda stated in an interview with the Battlefield Podcast that this match would be the "final chapter in my book" with regards to his career with professional wrestling.

title: Mike Chioda


text:
File:The ConstruKction of Light.jpg

Summary
Cover of the King Crimson album The construKction of light, 2000.

title: File:The ConstruKction of Light.jpg


text:
Talk:Mike Chioda

External links modified
Hello fellow Wikipedians,

I have just modified one external link on Mike Chioda. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20071226223443/http://www.wwe.com/shows/wrestlemania/history/wm21/mainevent/ to http://www.wwe.com/shows/wrestlemania/history/wm21/mainevent/

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Cheers.— InternetArchiveBot  (Report bug) 08:48, 11 June 2017 (UTC)

AEW
He's always been one of my favs just like earl hebner and i think he'd be a HUGE addition to the AEW roster so i hope it happens sooner rather than later — Preceding unsigned comment added by 2605:E000:110E:4A9D:405B:D57B:BD9E:944E (talk) 10:35, 20 June 2020 (UTC)

I love mike chioda
Bro is a goat PilatesHelps (talk) 04:44, 18 April 2022 (UTC)

title: Talk:Mike Chioda


text:
Princess (web series)

Princess is a Flash animation series by Matt Stone and Trey Parker, the creators of South Park. The story follows a Lhasa Apso dog.

On December 8, 1999, Daily Variety reported that Parker and Stone were going to produce 39 shorts that were to be 3-5 minutes long. In January 2000, the duo announced that they would have full creative and artistic control of the series.

The animated short was originally produced with Macromedia Flash in 2001 and was meant to be showcased on Macromedia's sister-site Shockwave. Stone and Parker never heard back from Shockwave after submitting the first two episodes.

Parker has stated that he and Stone would love to do more episodes if someone wanted to distribute them and has encouraged fans with Flash skills to continue the story themselves.

Princess Hears a Strange Noise
Princess is awakened by a strange squishing sound. It is her owner Richard being manually masturbated by his wife. She is unsuccessful in bringing him to orgasm because he has taken a large dose of Viagra. After three hours of sexual activity, the woman begins performing fellatio. When the fellatio is unsuccessful, Richard plays a porn movie on the television. When the porn movie is unsuccessful, he changes the channel to a show about interior decorating featuring Christopher Lowell, at which point he reaches orgasm. The force from the hours of sexual activity causes the semen to fly right through her head, killing her in the process. The episode ends with the semen-covered dog sneezing as Richard asks her "What are we going to do?"

Princess Meets Officer Friendly
Later in the morning, as police officers survey the scene, the husband gives information about the crime scene to Officer Friendly, the man in charge of the investigation. Officer Friendly says this is the 18th case of the aforementioned incident since Viagra was introduced to the public. Richard then goes to inform his son, Tommy, about the wife. Meanwhile, a man claiming to be a coroner enters the house and asks for 20 minutes alone with the body. In reality, he is a necrophiliac, and performs anal sex on the corpse. Princess tries to tell Officer Friendly and his partner (a parody of the television show Lassie) but they assume the dog is in heat. Princess then enters Tommy's room where Richard unsuccessfully attempts to explain to his son what happened. Princess barks and Tommy thinks the dog is telling him to "see Mommy". The episode ends with Tommy opening his parents' bedroom door to find the necrophiliac engaged in sexual acts with his mother's corpse.

Princess Finds a Red Balloon
At the end of the "Officer Friendly" episode, the viewers are invited to see the next installment, "Princess Finds A Red Balloon". However, according to South Park Studios, the episode was never produced following the rejection of the first two.

title: Princess (web series)


text: Wikipedia:Articles for deletion/Log/2005 July 20


text:
Wickeda

Wickeda (Уикеда ) are a Bulgarian rock band. They are quite popular in Bulgaria, and have occasionally topped the charts. Their style comprises punk, ska, reggae, funk and some traditional Bulgarian folk music elements. The witty lyrics filled with wordplay dealing mainly with stories from everyday life and the danceable tunes with memorable hooks have largely contributed to the band's success.

History
Wickeda are one of the most well-known bands in Bulgaria. When their first album Революция ("Revolution") appeared in 1999, it caught immediately the attention of musicians, journalists and music fans alike. The album was something of a turning point for the ailing Bulgarian popular music scene. It signalled the emergence of a new wave of Bulgarian rock and electronic bands on and around the label Жълта музика ("Yellow Music"). Bulgaria's leading music magazine at the time, New Rhythm chose it as one of the 35 best Bulgarian albums ever, and Wickeda won the prize for Best band and Best newcomer awarded by the music TV channel MM. The single " А ние с Боби двамата пием кафе" ("And I and Bobby, We are Both Drinking Coffee") stayed in MM's Top Ten for 10 weeks and the album sold over 30,000 copies.

In 2000 Wickeda released their second album Затова, защото... ("That's Why, Because..."). The first single, Уиски с фъстъци ("Whiskey and Peanuts") again reached high positions in the Top Ten. At the yearly MM-awards they won prizes for Best band and Best album. The second album sold over 20,000 copies.

The third album До тук ("Until Here"), a retrospective of Wickeda's work, came out in 2001, including four new songs. During their European tour (Czech Republic, Slovakia, Germany, Hungary), they released a single out of their fourth album Осъзнай се класово (approx. "Realise your Class Membership") in advance. After the tour the album was completed and managed once again to make it into the Top Ten.

In the summer of 2004 came the fifth and final album called 1618. There were some new Balkan influences, while the style of the band was still varied and got even harder. A lot of the tracks on the album were English translations of older songs, albeit three new songs, "Секси" (Sexy), "Ми да" (I'm Here!) and "The Letter", were added. The Bulgarian version of "The Letter" has never been released, although the CD-Text of 1618 refers to it as "Pismo nov voc". In the autumn Wickeda made another European tour presenting their new album in Hungary, the Czech Republic, Germany, the Netherlands, and Bulgaria.

In October 2009 UK dubstep producer Ramadanman, in conjunction with the British Council and Hessle Audio, released a 500 limited edition white label remix 12" single of the Wickeda track "А Ние Двамата с Боби Пием Кафе" from their 1999 debut album 'Revolution'. The Hessle Audio co-owner and producer was approached by the council to remix a track picked by the Bulgarian public, drawn from a selection of their top 10 90's Bulgarian pop songs.

In 2010 they were headliners at Spirit of Burgas after Everlast couldn't make it because of sickness.

On 10 June 2018, bandleader Erol Ibrahimov announced the end of the band on his personal Facebook page, stating that the band "had no more to say" after 21 years.

In 2022, Wickeda reunited, and have since continued to perform live. A new album is also in the works.

Members

 * Erol Ibrahimov (vocals, bass)
 * Rosen Grygorov (guitar)
 * Vladimir Georgiev - Popa(drums)
 * Yassen Obretenov - Yashata (keyboard)

Discography

 * Revolyutsia (Революция) (1999)
 * Zatova, zashtoto... (Затова, защото...) (2000)
 * Do tuk (До тук) (2001)
 * Osaznay se klasovo (Осъзнай се класово) (2003)
 * 1618 (2004)

Tours and festivals
They have played numerous festivals and made several tours abroad, even overseas:
 * USA Tour, 2001
 * The Sziget Festival in Budapest, Hungary in 2000, 2001, 2002, 2004, 2005, 2007
 * The Taksirat Festival in North Macedonia (2002)
 * Croatia (Ska-/Reggae-/Dub-Festival 2002)
 * Slovakia (2002)
 * Greece (Agrinio Festival, 2002)
 * Germany (Fusion Festival, Rockxplosion, Stadt Festival 2003, Waltroper Parkfest 2004)
 * Club tour across Germany in Cologne, Berlin, Munich, Hamburg and Münster in 2002
 * The Netherlands (Wantijpop Festival 2005, Elastiek Festival 2005)

They have also had their own successful gigs in Prague and Budapest.

title: Wickeda