:strip_icc():strip_exif()/u/854/tmp18467.jpg?f=community)
Eventjes een nieuw topic, omdat ik graag benieuwd ben naar de reacties op me essay^H^H^H^H^H^Hposting 
. Het project komt niet van de grond, al een jaar (ofzo) al niet en dat moet ergens door komen. Ik probeer hierin een beetje uit te leggen over het hoe en waarom van het uitblijven van tweakos...
Ik zie 3 major problemen met het hele project:
1. Er is geen duidelijk doel.
2. Er is geen coordinatie.
3. Er is geen kennis.
Even toelichten:
1. Er is geen duidelijk doel.
Het eerste wat gebeurt tijdens een "software"-project is "het probleem". Iemand wil iets hebben en komt ervoor naar jou toe. In dit geval willen tweakers voor zichzelf een OS hebben. Dan ga je je afvragen: WAT wil je precies hebben (vanuit de gebruikers oogpunt). Dit is een stap (user requirement specification ook wel genoemd) dat de gebruiker verteld aan de programmeur wat hij wil. Op dit punt gaat het dus al finaal mis. Ten eerste wordt er TE hoog gegrepen omdat de ene helft op 64 bit wil draaien omdat dat later zo koel is. Snap dan wel dat 75% van de mensen die mee willen helpen afvallen (omdat ze geen systeem hebben, of omdat ze helemaal gek worden van emulators) en dat 75% van de gebruikers het niet eens kunnen gebruiken. (hoe vaak heb jij een OS gebruikt dat onder een emulator draait?).
Verder wil de ene helft al vanaf boot een VBE2.0 800x600 grafisch textmode schermpje, waardoor alle lage systemen (en videokaarten) afvallen. Ik draai hier bijvoorbeeld mijn firewall op een linux systeempje draaiend op een 486dx2-66 op een 8" hercules monitor. Geen tweakos voor mij dus.
Iedereen wil meteen games hebben, directx/opengl ondersteuning, mp3''s kunnen afspelen, minimaal via ipv6 kunnen internetten en op z''n minst een gui die zowel native win32 apps, als kde en gnome apps ondersteunen. Qt/GTK/Motif/Xlib ondersteuning vanuit de kernel etc etc etc etc etc etc...
Met andere woorden: je weet niet wat je wil en zolang je dat niet weet, dan heeft het absoluut geen zin om uberhaupt om maar 1 regel code te schrijven.
Mijn conclusie (en ondersteund door een wezenlijk portie aan "URS-specificatie"):
* Zorg voor duidelijkheid in wat je wilt. Stel dat alsjeblieft op een een specificatie.
* Stel je eisen niet te hoog en niet te onmogelijk. Je zal nooit linux, bsd, solaris of windows inhalen. Wees blij als je kunt booten en A''tjes en B''tjes in aparte tasks kan starten. Je zult *NOOOOIT* een singel mp3''tje kunnen inladen van schijf voordat je OS-basics op zijn minst fatsoenlijk werken. Dit soort stappen moet je nemen op het moment dat er fysiek user-applicaties kunnen worden geschreven, en dan twijfel ik aan het feit of dat een mp3-speler moet zijn..
* Maak een User Requirement Specificatie (of hoe je het ook wilt noemen). Ga kijken vanuit de gebruikers oogpunt over hoe hij (of jezelf) het wil hebben. Technische dingen zijn hier nog absoluut niet nodig en iedereen zal hier gewoon aan mee kunnen helpen.
* Zonder doel.. geen TweakOS.
2. Er is geen coordinatie.
Zijn er project-leiders? Zijn er mensen die andere mensen aan het werk kunnen zetten. Kun je taken verdelen? Doet niet iedereen hetzelfde? Zijn er geen 50 man bezig met een boot-sector en maar 1 met de fysieke kernel? Waar moet ik de kernel laden, wat voor descriptors heb ik voor gebruik, is er een basic Clib (tweaklib) voor de broodnodige asserts, printf''tjes en speaker-beepjes (lach maar, je zult ze hard nodig hebben). Wie doet wat? Waar moet ik naartoe voor vragen over de boot-sector? Waar laat ik mijn stukje van de source? Is er al iemand bezig met "idt.c"? Mijn code werkt niet helemaal, maar kan ik em alvast committen? Gebruiken we uberhaupt wel CVS/RVS? Wat is de policy en coding-standards? Hoe noem ik mijn functies? Hoe zien mijn header-files eruit? Hoe documenteer ik alles. Tabs gebruiken of 2 spaties voor identing. Gebruik ik: "if (!function())" of gebruik ik: "ret=function(). if (ret == 0)"; Error checkings? Gebruik ik int''s of s32?
Net zo belangrijk als geen doel: geen coordinatie. Er moet een groep mensen zijn die bepalen wat er in de kernel komt en wat niet. Deze mensen moeten natuurlijk flinke kennis van zaken hebben. Waarschijnlijk splitsen deze mensen de zaak uiteen in hapklare brokken, spelen het naar beneden, en die mensen splisten het nog verder uit of programmeren gewoon het "probleem" wat ze van boven hebben gekregen. Zonder deze manier van werken val je (zeker met veel mensen) snel in een chaos, weet niemand wie wat doet en wat ze uberhaupt moeten doen.
* Mijn conclusie (en ondersteund door een wezenlijk portie aan "project-managment"):
* Stel een hierarchie op. Zorg dat je mensen bovenaan hebben zitten die: A. mee willen helpen en B. weten waar ze over praten. Je hebt er niets aan om iemand op "managment"-niveau te zetten die alleen PHP kan, of iemand die net 2 weekjes aan het delphi''en is. Hiervoor heb je mensen nodig voor wie: [topic=80545] geen problemen opleveren. Mensen die weten wat er bij komt kijken hoe een OS is gebouwd, en het liefste mensen die een OS al hebben gebouwd (en dan valt 99.9% van de tweakers af, en blijven er nog 3 of 4 over). Zonder gein: het is gewoon belangrijk dat dit punt goed gaat. Werken aan software met veel man is al moeilijk, en werken aan moeilijke software met veel man is nog veel moeilijker. Als het in de top al fout gaat, dan kan iedereen nog zo goed zijn best doen, maar de stukjes zullen nooit goed in elkaar passen.
* Stel een functional design specification op. Dit kost tijd.. veel tijd en vormt de basis van je OS. Hierin staat alles technisch beschreven over hoe alles loopt. Wat doet de boot-sector, hoe laad de bootsector de kernel en waar. Wat doet de kernel, hoe zet je die modulair (of misschien juist niet) op. Hoe ziet mijn scheduling en task-managment eruit. Paging? Memory managment? Clib? Hoe moet ik programma''s laden en in wat voor formaat zijn die dan? etc etc etc etc
Je FDS is het draaiboek van je project. Net zoals in een film je weinig kunt uitvoeren zonder script, zal zonder FDS (of soortgelijk) er weinig van de grond komen.
* Zonder coordinatie.. geen TweakOS.
3. Er is geen kennis.
Als ik zo de P&W-topics en de tweakOS topics doorlees, dan denk ik niet dat we uberhaupt 10 man bij elkaar kunnen sprokkelen die in staat zijn een OS kunnen schrijven. Veel mensen doen mee omdat ze het gaaf vinden om mee te helpen, maar weten eigenlijk niet wat een OS schrijven inhoudt. Je hebt geen paperclip die zegt dat je iets fout doet en het zal niet bestaan uit het slepen van componenten op een form. Ik heb een beetje het gevoel dat veel mensen dit wel denken. Ok, niet zo dramatisch natuurlijk, maar laten we maar zeggen dat ze zich flink verkijken.
Op zich is dat niet erg, alles moet je namelijk leren en onder het bouwen van een OS leer je op z''n zachts gezegd.. veel. Zelfs de mensen die alles al schijnen te weten zullen steeds weer nieuwe dingen tegenkomen (waarschijnlijk).
Het fysieke probleem wat je dus krijgt, is dat er iemand een bootsectortje bouwt die naar PM switched, een kernel laad van diskette of schijf of bochs en dat een ander groepje de kernel begint te bouwen. Maar als deze groep niet weet HOE dat moet, dan loopt het natuurlijk ook dood en komt het uiteindelijk op neer dat er een select groepje mensen druk bezig is en de rest uit zijn neus aan het vreten is.
Het is dus belangrijk dat er kennis is, en kennis kan worden overgedragen aan de mensen die fysiek iets willen bouwen. Het is hartstikke fijn als er mensen zijn die 2 weken C kennen en willen meehelpen, maar er zal weinig zijn waaraan je mee KUNT helpen, hoe lullig het ook klinkt.
Misschien is het een verstandig idee, om te beginnen met een soort van "OS-programming" tutorial op tweakers die het allemaal een beetje uitlegt over wat er allemaal bij komt kijken.
http://www.midpec.com/djgpp/protmode/index0_1.html
http://www-scf.usc.edu/~csci402/crowley/lect5.html
http://www.nondot.org/sabre/os/ (makkelijk en duidelijk)
http://ivs.cs.uni-magdeburg.de/bs/lehre/wise9798/bs2/seminare/seminar3-eng.shtml
http://webster.cs.ucr.edu/Page_asm/Doc386/TOC.HTM
http://ironbark.bendigo.latrobe.edu.au/subjects/bitsys/oslect/lectlist.html
Laten we zeggen dat je dit soort dingen moet kennen voordat je kunt bouwen en op zich is het niet zo moeilijk, maar je moet het wel allemaal door hebben (net zoals wiskunde, alleen nam ik in ieder geval nooit de moeite om het door te krijgen).
Mijn conclusie (en ondersteund door een wezenlijk portie aan "OS-programmeer-kennis"):
* Kennis is programmeren. Programmeren is TweakOS. Kennis is macht. TweakOS is macht.
* Stel een OS-tutorial op voor mensen die wel willen helpen, maar niet weten hoe het allemaal zit.
* Stel een lijst van sites op met allerlei info over OS-programming en programmeren in het algemeen. Laat ze deze uit hun hoofd leren
* Zorg dat je je mensen zodanig goed verdeeld dat iedereen overal zit op plekken waar ze willen zitten en waar ze kunnen zitten anders hou je niemand meer over.
* Zonder kennis.. geen TweakOS.
Zow.. stukkie getypt.. Ik probeer hiermee alleen maar wat duidelijkheid te scheppen in wat er allemaal bij komt kijken voordat je ook maar 1 regel code getypt hebt. Waarschijnlijk zullen er maar weinig mensen zijn die echt software schrijven als beroep op een manier zoals het ECHT moet. VisualUML opstarten, 5 minuten spelen, printje maken en wegstoppen in een map versta ik hier niet onder, maar er zit gewoon een hele techniek achter het bouwen van zoiets. Ik heb het geleerd op 1 manier, maar er zullen er vast meerdere zijn, die uiteindelijk allemaal wel op elkaar neerkomen. Kleine projecten (die wel veel mensen hier doen, voor zowel werk als hobby) zijn meestal zodanig klein dat het een overkill wordt om het grootschalig aan te pakken, maar daar heb je op den duur wel profijt van. Documentatie is vaak ver te zoeken, en menig bedrijf moet doorgaan met de huidige software omdat aanpassingen of zelfs complete vervaning van de software niet of nauwelijk kan omdat er geen documentatie is over wat de software precies doet. Zie het maar als een vliegtuig zonder blauwdrukken, waarvoor je eventjes een automatische piloot in moet zetten. Als er ettelijke honderden kilometers aan kabel door de romp heenloopt, en 1tje ervan is voor het aansluiten van een automatische piloot (ALS ze daar bij het designen ervan over hebben nagedacht en alvast een kabel hebben getrokken), dan word je niet vrolijk, zeker niet wanneer al die kabels allemaal dezelfde kleur hebben.
Maar goed, nu word het allemaal een lulverhaal dus back to the point: Zoals gezegd is werken aan software met veel man is al moeilijk, en werken aan moeilijke software met veel man is nog veel moeilijker. Hou hier rekening mee en als er echt mensen zijn die het voortouw willen trekken (count me out) dan denk ik dat er best wel iets kan uitkomen. De conclusies die ik geschreven heb komen niet zomaar uit de lucht vallen en zijn echt wel gebaseerd op praktijk ervaringen van verschillende kanten. Sla ze niet in de wind zonder een goede reden want ik weet zeker dat zonder ze het project weer voor de ziljoenste keer weer zal doodvallen. (wat met zo verschrikkelijk veel leuke projecten gebeurd).
Greets,
Jay
. Het project komt niet van de grond, al een jaar (ofzo) al niet en dat moet ergens door komen. Ik probeer hierin een beetje uit te leggen over het hoe en waarom van het uitblijven van tweakos...Ik zie 3 major problemen met het hele project:
1. Er is geen duidelijk doel.
2. Er is geen coordinatie.
3. Er is geen kennis.
Even toelichten:
1. Er is geen duidelijk doel.
Het eerste wat gebeurt tijdens een "software"-project is "het probleem". Iemand wil iets hebben en komt ervoor naar jou toe. In dit geval willen tweakers voor zichzelf een OS hebben. Dan ga je je afvragen: WAT wil je precies hebben (vanuit de gebruikers oogpunt). Dit is een stap (user requirement specification ook wel genoemd) dat de gebruiker verteld aan de programmeur wat hij wil. Op dit punt gaat het dus al finaal mis. Ten eerste wordt er TE hoog gegrepen omdat de ene helft op 64 bit wil draaien omdat dat later zo koel is. Snap dan wel dat 75% van de mensen die mee willen helpen afvallen (omdat ze geen systeem hebben, of omdat ze helemaal gek worden van emulators) en dat 75% van de gebruikers het niet eens kunnen gebruiken. (hoe vaak heb jij een OS gebruikt dat onder een emulator draait?).
Verder wil de ene helft al vanaf boot een VBE2.0 800x600 grafisch textmode schermpje, waardoor alle lage systemen (en videokaarten) afvallen. Ik draai hier bijvoorbeeld mijn firewall op een linux systeempje draaiend op een 486dx2-66 op een 8" hercules monitor. Geen tweakos voor mij dus.
Iedereen wil meteen games hebben, directx/opengl ondersteuning, mp3''s kunnen afspelen, minimaal via ipv6 kunnen internetten en op z''n minst een gui die zowel native win32 apps, als kde en gnome apps ondersteunen. Qt/GTK/Motif/Xlib ondersteuning vanuit de kernel etc etc etc etc etc etc...
Met andere woorden: je weet niet wat je wil en zolang je dat niet weet, dan heeft het absoluut geen zin om uberhaupt om maar 1 regel code te schrijven.
Mijn conclusie (en ondersteund door een wezenlijk portie aan "URS-specificatie"):
* Zorg voor duidelijkheid in wat je wilt. Stel dat alsjeblieft op een een specificatie.
* Stel je eisen niet te hoog en niet te onmogelijk. Je zal nooit linux, bsd, solaris of windows inhalen. Wees blij als je kunt booten en A''tjes en B''tjes in aparte tasks kan starten. Je zult *NOOOOIT* een singel mp3''tje kunnen inladen van schijf voordat je OS-basics op zijn minst fatsoenlijk werken. Dit soort stappen moet je nemen op het moment dat er fysiek user-applicaties kunnen worden geschreven, en dan twijfel ik aan het feit of dat een mp3-speler moet zijn..
* Maak een User Requirement Specificatie (of hoe je het ook wilt noemen). Ga kijken vanuit de gebruikers oogpunt over hoe hij (of jezelf) het wil hebben. Technische dingen zijn hier nog absoluut niet nodig en iedereen zal hier gewoon aan mee kunnen helpen.
* Zonder doel.. geen TweakOS.
2. Er is geen coordinatie.
Zijn er project-leiders? Zijn er mensen die andere mensen aan het werk kunnen zetten. Kun je taken verdelen? Doet niet iedereen hetzelfde? Zijn er geen 50 man bezig met een boot-sector en maar 1 met de fysieke kernel? Waar moet ik de kernel laden, wat voor descriptors heb ik voor gebruik, is er een basic Clib (tweaklib) voor de broodnodige asserts, printf''tjes en speaker-beepjes (lach maar, je zult ze hard nodig hebben). Wie doet wat? Waar moet ik naartoe voor vragen over de boot-sector? Waar laat ik mijn stukje van de source? Is er al iemand bezig met "idt.c"? Mijn code werkt niet helemaal, maar kan ik em alvast committen? Gebruiken we uberhaupt wel CVS/RVS? Wat is de policy en coding-standards? Hoe noem ik mijn functies? Hoe zien mijn header-files eruit? Hoe documenteer ik alles. Tabs gebruiken of 2 spaties voor identing. Gebruik ik: "if (!function())" of gebruik ik: "ret=function(). if (ret == 0)"; Error checkings? Gebruik ik int''s of s32?
Net zo belangrijk als geen doel: geen coordinatie. Er moet een groep mensen zijn die bepalen wat er in de kernel komt en wat niet. Deze mensen moeten natuurlijk flinke kennis van zaken hebben. Waarschijnlijk splitsen deze mensen de zaak uiteen in hapklare brokken, spelen het naar beneden, en die mensen splisten het nog verder uit of programmeren gewoon het "probleem" wat ze van boven hebben gekregen. Zonder deze manier van werken val je (zeker met veel mensen) snel in een chaos, weet niemand wie wat doet en wat ze uberhaupt moeten doen.
* Mijn conclusie (en ondersteund door een wezenlijk portie aan "project-managment"):
* Stel een hierarchie op. Zorg dat je mensen bovenaan hebben zitten die: A. mee willen helpen en B. weten waar ze over praten. Je hebt er niets aan om iemand op "managment"-niveau te zetten die alleen PHP kan, of iemand die net 2 weekjes aan het delphi''en is. Hiervoor heb je mensen nodig voor wie: [topic=80545] geen problemen opleveren. Mensen die weten wat er bij komt kijken hoe een OS is gebouwd, en het liefste mensen die een OS al hebben gebouwd (en dan valt 99.9% van de tweakers af, en blijven er nog 3 of 4 over
). Zonder gein: het is gewoon belangrijk dat dit punt goed gaat. Werken aan software met veel man is al moeilijk, en werken aan moeilijke software met veel man is nog veel moeilijker. Als het in de top al fout gaat, dan kan iedereen nog zo goed zijn best doen, maar de stukjes zullen nooit goed in elkaar passen.* Stel een functional design specification op. Dit kost tijd.. veel tijd en vormt de basis van je OS. Hierin staat alles technisch beschreven over hoe alles loopt. Wat doet de boot-sector, hoe laad de bootsector de kernel en waar. Wat doet de kernel, hoe zet je die modulair (of misschien juist niet) op. Hoe ziet mijn scheduling en task-managment eruit. Paging? Memory managment? Clib? Hoe moet ik programma''s laden en in wat voor formaat zijn die dan? etc etc etc etc
Je FDS is het draaiboek van je project. Net zoals in een film je weinig kunt uitvoeren zonder script, zal zonder FDS (of soortgelijk) er weinig van de grond komen.
* Zonder coordinatie.. geen TweakOS.
3. Er is geen kennis.
Als ik zo de P&W-topics en de tweakOS topics doorlees, dan denk ik niet dat we uberhaupt 10 man bij elkaar kunnen sprokkelen die in staat zijn een OS kunnen schrijven. Veel mensen doen mee omdat ze het gaaf vinden om mee te helpen, maar weten eigenlijk niet wat een OS schrijven inhoudt. Je hebt geen paperclip die zegt dat je iets fout doet en het zal niet bestaan uit het slepen van componenten op een form. Ik heb een beetje het gevoel dat veel mensen dit wel denken. Ok, niet zo dramatisch natuurlijk, maar laten we maar zeggen dat ze zich flink verkijken.
Op zich is dat niet erg, alles moet je namelijk leren en onder het bouwen van een OS leer je op z''n zachts gezegd.. veel
. Zelfs de mensen die alles al schijnen te weten zullen steeds weer nieuwe dingen tegenkomen (waarschijnlijk).Het fysieke probleem wat je dus krijgt, is dat er iemand een bootsectortje bouwt die naar PM switched, een kernel laad van diskette of schijf of bochs en dat een ander groepje de kernel begint te bouwen. Maar als deze groep niet weet HOE dat moet, dan loopt het natuurlijk ook dood en komt het uiteindelijk op neer dat er een select groepje mensen druk bezig is en de rest uit zijn neus aan het vreten is.
Het is dus belangrijk dat er kennis is, en kennis kan worden overgedragen aan de mensen die fysiek iets willen bouwen. Het is hartstikke fijn als er mensen zijn die 2 weken C kennen en willen meehelpen, maar er zal weinig zijn waaraan je mee KUNT helpen, hoe lullig het ook klinkt.
Misschien is het een verstandig idee, om te beginnen met een soort van "OS-programming" tutorial op tweakers die het allemaal een beetje uitlegt over wat er allemaal bij komt kijken.
http://www.midpec.com/djgpp/protmode/index0_1.html
http://www-scf.usc.edu/~csci402/crowley/lect5.html
http://www.nondot.org/sabre/os/ (makkelijk en duidelijk)
http://ivs.cs.uni-magdeburg.de/bs/lehre/wise9798/bs2/seminare/seminar3-eng.shtml
http://webster.cs.ucr.edu/Page_asm/Doc386/TOC.HTM
http://ironbark.bendigo.latrobe.edu.au/subjects/bitsys/oslect/lectlist.html
Laten we zeggen dat je dit soort dingen moet kennen voordat je kunt bouwen en op zich is het niet zo moeilijk, maar je moet het wel allemaal door hebben (net zoals wiskunde, alleen nam ik in ieder geval nooit de moeite om het door te krijgen
).Mijn conclusie (en ondersteund door een wezenlijk portie aan "OS-programmeer-kennis"):
* Kennis is programmeren. Programmeren is TweakOS. Kennis is macht. TweakOS is macht.
* Stel een OS-tutorial op voor mensen die wel willen helpen, maar niet weten hoe het allemaal zit.
* Stel een lijst van sites op met allerlei info over OS-programming en programmeren in het algemeen. Laat ze deze uit hun hoofd leren
* Zorg dat je je mensen zodanig goed verdeeld dat iedereen overal zit op plekken waar ze willen zitten en waar ze kunnen zitten anders hou je niemand meer over.
* Zonder kennis.. geen TweakOS.
Zow.. stukkie getypt.. Ik probeer hiermee alleen maar wat duidelijkheid te scheppen in wat er allemaal bij komt kijken voordat je ook maar 1 regel code getypt hebt. Waarschijnlijk zullen er maar weinig mensen zijn die echt software schrijven als beroep op een manier zoals het ECHT moet. VisualUML opstarten, 5 minuten spelen, printje maken en wegstoppen in een map versta ik hier niet onder, maar er zit gewoon een hele techniek achter het bouwen van zoiets. Ik heb het geleerd op 1 manier, maar er zullen er vast meerdere zijn, die uiteindelijk allemaal wel op elkaar neerkomen. Kleine projecten (die wel veel mensen hier doen, voor zowel werk als hobby) zijn meestal zodanig klein dat het een overkill wordt om het grootschalig aan te pakken, maar daar heb je op den duur wel profijt van. Documentatie is vaak ver te zoeken, en menig bedrijf moet doorgaan met de huidige software omdat aanpassingen of zelfs complete vervaning van de software niet of nauwelijk kan omdat er geen documentatie is over wat de software precies doet. Zie het maar als een vliegtuig zonder blauwdrukken, waarvoor je eventjes een automatische piloot in moet zetten. Als er ettelijke honderden kilometers aan kabel door de romp heenloopt, en 1tje ervan is voor het aansluiten van een automatische piloot (ALS ze daar bij het designen ervan over hebben nagedacht en alvast een kabel hebben getrokken), dan word je niet vrolijk, zeker niet wanneer al die kabels allemaal dezelfde kleur hebben.
Maar goed, nu word het allemaal een lulverhaal dus back to the point: Zoals gezegd is werken aan software met veel man is al moeilijk, en werken aan moeilijke software met veel man is nog veel moeilijker. Hou hier rekening mee en als er echt mensen zijn die het voortouw willen trekken (count me out) dan denk ik dat er best wel iets kan uitkomen. De conclusies die ik geschreven heb komen niet zomaar uit de lucht vallen en zijn echt wel gebaseerd op praktijk ervaringen van verschillende kanten. Sla ze niet in de wind zonder een goede reden want ik weet zeker dat zonder ze het project weer voor de ziljoenste keer weer zal doodvallen. (wat met zo verschrikkelijk veel leuke projecten gebeurd).
Greets,
Jay
Yo dawg, I heard you like posts so I posted below your post so you can post again.
)
:strip_icc():strip_exif()/u/6607/klootviool2.jpg?f=community)
/u/858/logo_rgb60.png?f=community){kind=logo}
:strip_exif()/u/3587/terran.gif?f=community)
..........:Z .......... ehhhhmmm....zei je iets?
:strip_exif()/u/12636/icon2.gif?f=community)
:strip_icc():strip_exif()/u/16422/crop5aeaddaca37a5_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/1522/crop5f4a0291a77ba_cropped.jpeg?f=community)
/u/20461/crop57d9660f4ca9e_cropped.png?f=community)
:strip_icc():strip_exif()/u/3211/crop59feeb45b9cc1_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/2032/rorty2.jpg?f=community)
:strip_icc():strip_exif()/u/21/crop69f04ee6196b5_cropped.jpg?f=community)
/u/1983/whiteButton.png?f=community)