0 users browsing Discussion. | 1 guest | 13 bots
| CaptainJistuce |
Posted on 19-09-29, 22:10
|
|
Custom title here
 Post: #715 of 1164 Since: 10-30-18 Last post: 63 days Last view: 16 hours |
Posted by Kawa Well, yes, clearly. But somehow the only place where it is genuinely advantageous to ignore it(web browsers) is also the only place it is respected. --- In UTF-16, where available. --- |
| wareya |
Posted on 19-09-30, 02:11
|
 Post: #91 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
A mistake. A big, fat, huge mistake. The sRGB gamma curve should have been defined as a fixed exponent of 2 so that conversion between linear and gamma-compressed space was trivial, and so that it was different enough from displays that graphics vendors were required to actually convert if their monitor didn't actually follow the sRGB gamma curve. |
| CaptainJistuce |
Posted on 19-09-30, 02:33
|
|
Custom title here
Post: #717 of 1164 Since: 10-30-18 Last post: 63 days Last view: 16 hours |
Wasn't sRGB kind of a shitty standard to start with? As I recall it was an attempt to make a documented standard based on the typical display system of the time, which of course means it became a de facto standard because everyone was already using it, and makes the modern displays that can't even hit the entire sRGB color space all the more embarrassing since they're failing to meet a standard that was by design a representation of the mid-1990s mainstream. --- In UTF-16, where available. --- |
| wareya |
Posted on 19-09-30, 03:05
|
|
Post: #92 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
Something like that. The worst part of it is the linear part of the gamma ramp, which just means that people implement it incorrectly (because an exponent is Good Enough™). The general idea is fine. If we're only storing 255 brightness levels per channel we should DEFINITELY gamma-compress them. The question is how much, with what curve, and how the representation is chromatically defined. |
| CaptainJistuce |
Posted on 19-09-30, 03:32
|
|
Custom title here
Post: #718 of 1164 Since: 10-30-18 Last post: 63 days Last view: 16 hours |
Posted by wareyaI say 8 bits per channel was good enough for 1995, but a quarter-century later we should DEFINITELY be seeing advancement. I'm outraged that for most systems 24-bit color is still the cap. --- In UTF-16, where available. --- |
| Kawaoneechan |
Posted on 19-09-30, 10:38
|
|
Felin in Chief
 Post: #414 of 599 Since: 10-29-18 Last post: 196 days Last view: 38 min. |
Posted by CaptainJistuceSystem 7 from 1991 disagreed, even if this was only to define colors. The fact that it says 16, 256, thousands, or millions of colors in the mode window implies it's downscaled to 8 bits per channel. Dumb DTP thing? |
| wareya |
Posted on 19-09-30, 10:41
|
|
Post: #93 of 100 Since: 10-30-18 Last post: 1782 days Last view: 1347 days |
There's always dithering! |
| CaptainJistuce |
Posted on 19-09-30, 11:10
|
|
Custom title here
Post: #720 of 1164 Since: 10-30-18 Last post: 63 days Last view: 16 hours |
Posted by KawaI'm certain it was 24-bit color in the display path, as per hardware documentation. Hell, look at the color banding on that selector, that window's not even 24-bit. Possibly for printing purposes, possibly just Apple being Apple. Also possible they intended to go farther but RAM prices got in the way at the time. --- In UTF-16, where available. --- |
| tomman |
Posted on 19-10-04, 20:29
|
|
Dinosaur
 Post: #569 of 1316 Since: 10-30-18 Last post: 4 hours Last view: 4 hours |
The once unhackable Wii Mini has now been successfully cracked wide open, ready for https://github.com/Fullmetal5/bluebomb Nintendo: "We've removed WiFi and SD for your security, good luck Fullmetal5: "Hold my beer" Unfortunately this hax is not for the random PokèRAWMz kid at home, as it requires access to a Real Computer running Linux with a Bluetooth adapter (ideally a laptop), the ability to build stuff from source (it uses vanilla Bluez userspace, albeit built with some deprecated features, hence you can't use the one shipped by your distro as you will have to disable it prior to using bluebomb - hope you are not using a BT keyboard! Thus, a VM with USB passthrough is highly desirable here), and following instructions ("butbutbut I am not a NASA hacker!!!") As a bonus, bluebomb also works on older, uncrippled Wiis (I guess this should be the way to go if somehow you don't have a <4GB SD card handy yet you own a Bluetooth-enabled laptop and an USB stick) Nice to see one of those "OOOH SCARY!!!" wireless vulnerabilities out in the wild being used for good and not for evil. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Lurking Star |
Posted on 19-10-05, 23:28
|
|
Post: #12 of 17
Since: 06-02-19 Last post: 1692 days Last view: 1691 days |
Posted by tomman Str2Hax exists if you don't have a SD handy, but it requires using a random DNS that may go down at any point. So this is handy for that future. |
| CaptainJistuce |
Posted on 19-10-06, 00:25
|
|
Custom title here
Post: #735 of 1164 Since: 10-30-18 Last post: 63 days Last view: 16 hours |
Posted by Lurking Star https://github.com/Fullmetal5/str2hax You SHOULD be able to set this up on a local system and point the Wii towards it, removing a dependency on outside servers. That's workable until Microsoft shuts down Github(any day now, right?). --- In UTF-16, where available. --- |
| Lurking Star |
Posted on 19-10-06, 02:05
|
|
Post: #13 of 17
Since: 06-02-19 Last post: 1692 days Last view: 1691 days |
Posted by CaptainJistuce I was going to mention that in my post, but it slipped my mind. Curse you, ADHD. |
| Kawaoneechan |
Posted on 19-10-07, 23:32
|
|
The Sufferer
Post: #424 of 599 Since: 10-29-18 Last post: 196 days Last view: 38 min. |
So here's a thing I think I'll bait Tom with. Adobe is deactivating all accounts in Venezuela |
| creaothceann |
Posted on 19-10-11, 19:13
|
 Post: #207 of 456 Since: 10-29-18 Last post: 44 days Last view: 1 day |
"If this weren't a livestream I would punch you!" My current setup: Super Famicom ("2/1/3" SNS-CPU-1CHIP-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10 |
| CaptainJistuce |
Posted on 19-10-12, 00:15 (revision 1)
|
|
Custom title here
Post: #736 of 1164 Since: 10-30-18 Last post: 63 days Last view: 16 hours |
Posted by KawaSeems like that should hit a lot of services, not just the mud. RIP Tomman's Steam account. Edit: Except I just read the executive order and Adobe's just slinging mud. It calls for the seizing of venezuelan government assets, not banning everyone suffering under the dictator's yoke. --- In UTF-16, where available. --- |
| tomman |
Posted on 19-10-12, 00:41
|
|
Dinosaur
Post: #571 of 1316 Since: 10-30-18 Last post: 4 hours Last view: 4 hours |
Posted by CaptainJistuce Yup, but then Adobe is not in the business of telling which Venezuelans are pro-communism and which ones are actually starving to death. Plus, you can't buy software with our creditcards thanks to our never-ending currency exchange controls (you can now go to a bank and "buy greenbacks", but only in cash, and after jumping a vat full of flaming, acid-soaked angry cobras, but our Visas and MasterCards are forever barred from the global market), so I guess the number of impacted users is in the low thousands (mainly newspapers and some graphic designers that actually pay for their shit, instead of pirating everything like it has been done since forever). This is a dire reminder that... - DRM means that you don't own shit. You're renting a permission of use that can be revoked AT ANY TIME. - "Sanctions" means jack shit, little more than useless token efforts. IF anything they cause the commies to become more bloody murderers than ever, because they will try their hardest to convince their slaves that "USA is the enemy!". But then, since when 'murica (or anyone else) has gave a shit about us anyway? - This can also hit your beloved open source software. Remember, Microsoft now owns GitHub, and this means that if one of their useless lawyers decides to pull an Adobe, it means that I'll be out of a job, forever. Not that I would care that much if my Steam account goes down the shitter, as I only get TEN MINUTES of DSL access every 3 days... if I'm lucky. Even DRM-free software is fucking useless if you can't even download the freakin' installers in first place! Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| tomman |
Posted on 19-10-12, 05:29
|
|
Dinosaur
Post: #572 of 1316 Since: 10-30-18 Last post: 4 hours Last view: 4 hours |
Never ever ever EVUR! neglect properly implementing equals/hashCode methods in Java (or whatever language you're using): https://www.journaldev.com/21095/java-equals-hashcode https://stackoverflow.com/questions/27581/what-issues-should-be-considered-when-overriding-equals-and-hashcode-in-java If you're relying on your IDE to take care for you, that decision is going to come back several years later down the road and bite in yer' ass. HARD. No mercy! And the pain will not be a pleasure! True story: this happened to me on a story that started in 2014, and should have ended in 2018, but due to $REASON$. I'm still giving service to $FORMER_EMPLOYER_APP, now as a sort of external contractor (I take service calls from customers, patch bugs, deploy patches when CANTV allows me for the two customers for which I have remote access, and get paid a slice of the pie so I can actually eat it and not starve). Last month I got a call from a customer near me, the system was eating some records on some module. Since this customer is actually on the same bus road I take to the same place I get my worthless banknotes for my collection (i.e. a bank), I went in person to see the problem in action, and after 2 hours of reentering the same records just to have the system reject them because the sums were off at the end of the process, I whipped out my copy of good ol' pgAdmin III, just to notice that there were duplicate records on the database... something that should have been stopped by the server-side checks! After clearing the duplicate records and blaming cosmic radiation instead of PEBCAK (which usually is the source for ~80% of those service calls), I left the premises and went home. Tried replicating the problem at my setup, with no result: punching the same records at home failed to trigger any failure. Gotta love heisenbugs~ Yesterday, another customer calls. They had the EXACT SAME PROBLEM, but even worse as the app let them advance those records to a state they should haven't been (because the sums were off: on the first case that last server-side check actually worked, but not this time). After giving them a call after my DSL miraculously came back alive for enough time to remote in and pull the ~3MB PostgreSQL DB backup from the live production server, once again I failed to trigger any bugs. Or so I thought. On the next phone call, most likely the planets aligned, because one of our users managed to trigger the "eat some, dupe others" issue live and in real time: just open your records, DO ABSOLUTELY NOTHING, click "Save", and watch the world burn right after your eyes. And sure enough, this time I was actually able to fall in the trap and face the bastard bug face to face. But that was just the beginning of a long debugging struggle... In this specific setup, you have an ArrayList<SomeEntity>, and a bunch of SomeEntity objects. Said objects have a ID field, which is usually null until they're committed to the database, where an ID is autogenerated (and if you read them back to entity objects, you get a valid ID and not just "null"). So far, so good. On save, some validations are performed (we're dealing with money here, so it's the usual "input valid, non-zero amounts, and make sure your final sums are OK, because I'm not going to save mismatching amounts on your documents"). Since those record sets often involve large quantities of records, we let our lusers to save their progress every now and then and make all the edits they want until they're ready to commit their records to a final, immutable document. During this phase, our ArrayList<SomeEntity> is populated with copies of another ArrayList<SomeEntity> which are exact copies bar one field: the ID. The editable copy has their IDs set to null, and during save, we match those records through their other fields, discarding deletions and making new records for additions as required. Long short story: why in the fuck when I tell you "List.remove(someEntityWithNullIDButValidData)", will you remove someEntitiyWithNullIDButACompletelyDifferentContents instead after having worked flawlessly for FIVE yars?! Because my name is Cirno, the king of bakas, it seems! It took me hours to figure out that it was my equals() methods (which were kindly autogenerated by Netbeans years ago, thankyouverymuch And sure enough, after strengthening my equals() methods to dive in the actual contents of the object when you happen to be comparing null IDs, all this disaster went away in a flash - from Clownpiece-tier all the way down to "random noname Stage 1 fairy". FUN. And of course, if you touch equals(), you have to also update hashCode() to keep things consistent. So yeah, this time computerizers weren't outsmarting me, because I wasn't exactly complying with the API contract ("thou shall evaluate all of the relevant fields in your comparisons") because someone thought it was a good idea to only consider primary keys when autogenerating entity classes from DB tables on whatever Netbeans wizard they use to generate JPA entity classes. Sure, this makes sense if you're consuming already existing records or generating the IDs yourself. But in the real world, the devil is in the details. So... how did this obviously BROKEN code worked flawlessly for FIVE YEARS, until 4 weeks ago?! Why why why WHY!?!?!?!?!?!?! Man, that house of cards held quite strongly, but eventually it had to fall (and even then only a few cards fell down!). Fortunately (for me!), only two customers (out of five installs) were impacted, and only with a handful of recent records which were trivial to fix with a couple of SQL oneliners), but it could have been much much MUCH worse. I dodged quite a few cannonballs and nukes, just to end being hit by a Bart Simpson-level prank :/ Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
| Kawaoneechan |
Posted on 19-10-12, 06:18
|
|
Nazi science sneers at your custom titles!
Post: #425 of 599 Since: 10-29-18 Last post: 196 days Last view: 38 min. |
But man do you make those ten minutes count. |
| CaptainJistuce |
Posted on 19-10-12, 06:41
|
|
Custom title here
Post: #737 of 1164 Since: 10-30-18 Last post: 63 days Last view: 16 hours |
Posted by tommanDark magics. --- In UTF-16, where available. --- |
| tomman |
Posted on 19-10-12, 17:00
|
|
Dinosaur
Post: #573 of 1316 Since: 10-30-18 Last post: 4 hours Last view: 4 hours |
Posted by CaptainJistuce In other words, a schrödinbug. TIL there is also a higgs-bugson. Yes, I've experienced those too. At least one of those remain unfixed at $PRODUCT, because it's simply impossible to replicate it under any test setup, and it doesn't even happen at some deployments. Licensed Pirate® since 2006, 100% Buttcoin™-free, enemy of All Things JavaScript™ |
[Your ad here? Why not!]