History DarthWiki / IdiotProgramming

14th Jul '16 1:54:21 PM Digsu
Is there an issue? Send a Message

Added DiffLines:

* ''Wildlife Camp'' is a PC game released in 2010 that doesn't have an option to turn fullscreen mode off. This would be bad enough on its own, but if you open up the game's options.ini file, you'll find that the game ''does'' have a fullscreen toggle - the line of code that enables the button for it to appear has just been commented out. Re-enabling the code causes the fullscreen toggle to appear in-game and work without problem, which begs the question why it was DummiedOut in the first place, especially since being able to put your game in windowed mode is one of the most basic features a game can have.
11th Jul '16 6:39:25 PM LucaEarlgrey
Is there an issue? Send a Message


** ''VideoGame/PokemonGO'' [[http://adamreeve.tumblr.com/post/147120922009/pokemon-go-is-a-huge-security-risk requires full access to your Google account]] which is a ''massive'' security risk. To compare: ''VideoGame/{{Ingress}}'', another location-based AlternateRealityGame by Niantic, only requires the app to read your basic information.

to:

** ''VideoGame/PokemonGO'' [[http://adamreeve.tumblr.com/post/147120922009/pokemon-go-is-a-huge-security-risk requires full access to your Google account]] which account]]--i.e. allowing the app to do whatever it wants with your account--which is a ''massive'' security risk. To compare: ''VideoGame/{{Ingress}}'', another location-based AlternateRealityGame by Niantic, only requires the app to read (not write) your basic information. information (email address, anything public in your Google profile, etc.).
11th Jul '16 6:37:13 PM LucaEarlgrey
Is there an issue? Send a Message


** ''VideoGame/PokemonGO'' [[http://adamreeve.tumblr.com/post/147120922009/pokemon-go-is-a-huge-security-risk requires full access to your Google account]] which is a ''massive'' security risk; while it's unlikely Niantic is going to do anything malicious with your Google account, if they get compromised or accidentally do something that compromises Google accounts, it . To compare: ''VideoGame/{{Ingress}}'', another location-based AlternateRealityGame by Niantic, only requires the app to read your basic information.

to:

** ''VideoGame/PokemonGO'' [[http://adamreeve.tumblr.com/post/147120922009/pokemon-go-is-a-huge-security-risk requires full access to your Google account]] which is a ''massive'' security risk; while it's unlikely Niantic is going to do anything malicious with your Google account, if they get compromised or accidentally do something that compromises Google accounts, it .risk. To compare: ''VideoGame/{{Ingress}}'', another location-based AlternateRealityGame by Niantic, only requires the app to read your basic information.
11th Jul '16 6:34:09 PM LucaEarlgrey
Is there an issue? Send a Message


** ''VideoGame/PokemonGO'' [[http://adamreeve.tumblr.com/post/147120922009/pokemon-go-is-a-huge-security-risk requires full access to your Google account]] which is a ''massive'' security risk. To compare: ''VideoGame/{{Ingress}}'', another location-based AugmentedRealityGame by Niantic, only requires the app to read your basic information.

to:

** ''VideoGame/PokemonGO'' [[http://adamreeve.tumblr.com/post/147120922009/pokemon-go-is-a-huge-security-risk requires full access to your Google account]] which is a ''massive'' security risk. risk; while it's unlikely Niantic is going to do anything malicious with your Google account, if they get compromised or accidentally do something that compromises Google accounts, it . To compare: ''VideoGame/{{Ingress}}'', another location-based AugmentedRealityGame AlternateRealityGame by Niantic, only requires the app to read your basic information.
11th Jul '16 6:33:08 PM LucaEarlgrey
Is there an issue? Send a Message

Added DiffLines:

** ''VideoGame/PokemonGO'' [[http://adamreeve.tumblr.com/post/147120922009/pokemon-go-is-a-huge-security-risk requires full access to your Google account]] which is a ''massive'' security risk. To compare: ''VideoGame/{{Ingress}}'', another location-based AugmentedRealityGame by Niantic, only requires the app to read your basic information.
7th Jul '16 12:59:53 PM Fallingwater
Is there an issue? Send a Message

Added DiffLines:

* Among the many marketing and management screwups that doomed the Minidisc in classical Sony fashion, the few technical issues of the format tend to get lost in the noise - but there is one irritation that plagued Minidisc from the start. If your portable recorder was bumped while writing the TOC - that is, the partition table, as opposed to the actual data on the storage part of the disk - and managed to burn bad data into it, it would render the disk completely unusable. Players wouldn't recognize it anymore and it was impossible to re-record the bad TOC with a good one, despite the rewritable nature of the media. The kicker: the inability to rewrite a good TOC wasn't a hardware limitation, it's just that ''nobody thought of programming it into the recorders'', whose mechanisms were otherwise perfectly capable of doing it. This is evident because there are a small number of early models - rare and expensive even then, let alone now - that do have a TOC-restoring feature - ''hidden in the debug menu'', of course, because why would any normal user ever need that?
7th Jul '16 6:17:40 AM Fallingwater
Is there an issue? Send a Message

Added DiffLines:

* Famously, the "PC LOAD LETTER" message you'd get on early HP Laserjets has been elevated as an example of confusion in user interfaces. Anyone without prior knowledge would assume something is wrong with the connection to the PC, or something is off in the transfer of data ("load" being interpreted as "upload"), and that the printer is refusing the "letter" they're trying to print. What it actually means is "load letter-sized paper into paper cassette"; why the printer wasn't simply programmed to say "OUT OF PAPER" is a RiddleForTheAges.
24th Jun '16 12:41:36 PM passivesmoking
Is there an issue? Send a Message


** While the Prescott iteration of the design had some very special problems of its own, the Pentium 4 architecture in general had a rather unenviable reputation for underperforming. The design was heavily optimised in favour of being able to clock to high seeds in an attempt to win the "megahertz war" on the grounds that consumers at the time believed that higher clock speed = higher performance. The sacrifices made in the P4 architecture in order to achieve those high clock speeds, however, resulted in very poor performance per tick of the processor clock. For example the processor had a very long instruction decode pipeline [[note]]a pipeline is a device that breaks the fetch/decode/execute cycle into subtasks that can be executed in an assembly line style so that while one instruction is being sent to the ALU for execution, the next in the sequence is being decoded and the one after that is being fetched, allowing 1 instruction per clock cycle instead of 1 instruction taking several cycles[[/node]], which was fine if the program being executed didn't do anything unexpected like jump to a new instruction, but if it did it would cause all instructions in the pipeline to be discarded, stalling the processor until the new program execution flow was loaded into the pipeline, and because the pipeline was a lot deeper than the previous Pentium III, the processor would stall for several clock cycles while the pipeline was purged and refreshed. The science of branch prediction was in its infancy at that point, so pipeline stalls were a common occurrence on Pentium 4 processors. This combined with other bone-headed design decisions like the omission of a barrel shifter[[note]]a device that can do shift operations to an arbitrary number of places in a single clock cycle, as opposed to shifting a single step per clock cycle until the desired result is achieved[[/note]] and providing multiple execution units but only having one be able to execute per clock cycle under most circumstances meant that the contemporary Athlon processor from AMD could eat the P4 alive at the same clock speed due to a far more efficient design (The last problem was partially solved with the concept of "hyperthreading", presenting a single core processor to the OS as a 2 core processor, and using some clever trickery in the chip itself to allow the execution units that would otherwise sit idle to execute a second instruction in parallele provided it meets certain criteria).

to:

** While the Prescott iteration of the design had some very special problems of its own, the Pentium 4 architecture in general had a rather unenviable reputation for underperforming. The design was heavily optimised in favour of being able to clock to high seeds speeds in an attempt to win the "megahertz war" on the grounds that consumers at the time believed that higher clock speed = higher performance. The sacrifices made in the P4 architecture in order to achieve those high clock speeds, however, resulted in very poor performance per tick of the processor clock. For example the processor had a very long instruction decode pipeline [[note]]a pipeline is a device that breaks the fetch/decode/execute cycle into subtasks that can be executed in an assembly line style so that while one instruction is being sent to the ALU for execution, the next in the sequence is being decoded and the one after that is being fetched, allowing 1 instruction per clock cycle instead of 1 instruction taking several cycles[[/node]], cycles[[/note]], which was fine if the program being executed didn't do anything unexpected like jump to a new instruction, but if it did it would cause all instructions in the pipeline to be discarded, stalling the processor until the new program execution flow was loaded into the pipeline, and because the pipeline was a lot deeper than the previous Pentium III, the processor would stall for several clock cycles while the pipeline was purged and refreshed. The science of branch prediction was in its infancy at that point, so pipeline stalls were a common occurrence on Pentium 4 processors. This combined with other bone-headed design decisions like the omission of a barrel shifter[[note]]a device that can do shift operations to an arbitrary number of places in a single clock cycle, as opposed to shifting a single step per clock cycle until the desired result is achieved[[/note]] and providing multiple execution units but only having one be able to execute per clock cycle under most circumstances meant that the contemporary Athlon processor from AMD could eat the P4 alive at the same clock speed due to a far more efficient design (The last problem was partially solved with the concept of "hyperthreading", presenting a single core processor to the OS as a 2 core processor, and using some clever trickery in the chip itself to allow the execution units that would otherwise sit idle to execute a second instruction in parallele provided it meets certain criteria).
24th Jun '16 12:39:52 PM passivesmoking
Is there an issue? Send a Message

Added DiffLines:

** While the Prescott iteration of the design had some very special problems of its own, the Pentium 4 architecture in general had a rather unenviable reputation for underperforming. The design was heavily optimised in favour of being able to clock to high seeds in an attempt to win the "megahertz war" on the grounds that consumers at the time believed that higher clock speed = higher performance. The sacrifices made in the P4 architecture in order to achieve those high clock speeds, however, resulted in very poor performance per tick of the processor clock. For example the processor had a very long instruction decode pipeline [[note]]a pipeline is a device that breaks the fetch/decode/execute cycle into subtasks that can be executed in an assembly line style so that while one instruction is being sent to the ALU for execution, the next in the sequence is being decoded and the one after that is being fetched, allowing 1 instruction per clock cycle instead of 1 instruction taking several cycles[[/node]], which was fine if the program being executed didn't do anything unexpected like jump to a new instruction, but if it did it would cause all instructions in the pipeline to be discarded, stalling the processor until the new program execution flow was loaded into the pipeline, and because the pipeline was a lot deeper than the previous Pentium III, the processor would stall for several clock cycles while the pipeline was purged and refreshed. The science of branch prediction was in its infancy at that point, so pipeline stalls were a common occurrence on Pentium 4 processors. This combined with other bone-headed design decisions like the omission of a barrel shifter[[note]]a device that can do shift operations to an arbitrary number of places in a single clock cycle, as opposed to shifting a single step per clock cycle until the desired result is achieved[[/note]] and providing multiple execution units but only having one be able to execute per clock cycle under most circumstances meant that the contemporary Athlon processor from AMD could eat the P4 alive at the same clock speed due to a far more efficient design (The last problem was partially solved with the concept of "hyperthreading", presenting a single core processor to the OS as a 2 core processor, and using some clever trickery in the chip itself to allow the execution units that would otherwise sit idle to execute a second instruction in parallele provided it meets certain criteria).
23rd Jun '16 4:24:53 AM Fallingwater
Is there an issue? Send a Message


* The Commodore 64, one of the most popular computers of all time, wasn't without its share of problems. Perhaps the most widely known is its ''extreme'' slowness at loading programs. This couldn't really be helped with a storage medium like tape, which remained slow even after various clever solutions to speed it up, but floppy disks really ought to have been faster. What happened was that Commodore had devised a hardware-accelerated system for transferring data that worked fairly well, but then also found a hardware bug in the input/output chip that made it work not at all. Replacing the buggy chips was economically unfeasible, so the whole thing was revised to [[https://en.wikipedia.org/wiki/Bit_banging work entirely in software]]. This slowed down drive access immensely and caused the birth of a cottage industry for speeder carts, replacement ROM chips and fastloaders, most of which sped things up at least fivefold. Additionally the drive itself had a CPU and some RAM to spare - effectively a secondary computer dedicated to the sole task of feeding data to the primary computer - so it was programmable, and people came up with their own ways to improve things further. Eventually non-standard formats were developed that loaded ''25 times as fast as normal''.

to:

* The Commodore 64, one of the most popular computers of all time, wasn't without its share of problems. Perhaps the most widely known is its ''extreme'' slowness at loading programs. This couldn't really be helped with a storage medium like tape, which remained slow even after various clever solutions to speed it up, but floppy disks really ought to have been faster. What happened was that Commodore had devised a hardware-accelerated system for transferring data that worked fairly well, but then also found a hardware bug in the input/output chip that made it work not at all. Replacing the buggy chips was economically unfeasible, so the whole thing was revised to [[https://en.wikipedia.org/wiki/Bit_banging work entirely in software]]. This slowed down drive access immensely and caused the birth of a cottage industry for speeder carts, replacement ROM chips and fastloaders, most of which sped things up at least fivefold. Additionally the drive itself had a CPU and some RAM to spare - effectively a secondary computer dedicated to the sole task of feeding data to the primary computer (hence its phenomenal cost) - so it was programmable, and people came up with their own ways to improve things further. Eventually non-standard formats were developed that loaded ''25 times as fast as normal''.
This list shows the last 10 events of 1044. Show all.
http://tvtropes.org/pmwiki/article_history.php?article=DarthWiki.IdiotProgramming