|
Suspicious Dish posted:People often get the Ruby community and the Rails community mixed up. The Rails community is full of people like David "omakase" Hansson, while the Ruby community is lead by matz, who is the most courteous and kind person ever. matz on diversity "let em eat rails girls" https://twitter.com/yukihiro_matz/status/380394450746216448 "@rubyconf is not a tool to solve our social problem. If the program has no explicit discrimination, let it be. We have RailsGirls instead."
|
#
¿
May 4, 2014 19:40
|
|
|
|
| # ¿ May 15, 2024 01:04 |
|
|
Smugdog Millionaire posted:Why would I read any of this when I can feel outraged & superior instead?? Although we can interpret the first bit in a number of air quotes, the followup is less damning, but is as easily interpreted one way or the other. it was provided as an example of matz not being so nice.
|
|
#
¿
May 7, 2014 00:44
|
|
|
..btt posted:Truly, you have embraced the Ruby philosophy. Is this, we should be judged as if we are matz but act as if we are dhh?
|
|
#
¿
May 7, 2014 00:46
|
|
|
Hammerite posted:I thought the argument for NodeJS was that you could write the client-side and server-side code in the same language, and potentially share some code libraries between the two. I can't see what the argument would be for having JavaScript code running on an Arduino-like device. As with many things in life: It depends. Node kicked off because V8 happened. A separate, easy to embed JIT. At the time, very few good jits existed for dynamic languages, or the popular implementations in use were just bytecode interpreters. As a result, you could in theory write faster javascript than you could write faster code in other comparable languages. The next big difference is that node's http interface wasn't built around CGI. i.e, you could use modern features like websockets. Meanwhile, python, ruby et al, with WSGI, Rack were stuck with the "call this function, return this status code and data" interface. This is what some people meant when they said "closer to the metal", it was easier to use websockets in Node, and many more HTTP shenanigans. So someone bolted a http server to a javascript runtime. It made sense for a bunch of small http toy backends. Low demands and often fun to build. Node is a lot newer than Python or Ruby, and learned from their experience - getting some form of package management far quicker than they did. So for someone who wanted websockets, or maybe just wanted to start moving from client side code to server code, Node made it obscenely easy. Similarly, PHP let people move from HTML, to templates, to web applications talking to databases incredibly easy. Like with many pieces of popular software, it has a contingent of assholes and zealots. Rails has DHH and mountains of hacker news posters, and years before Perl had an army of slashdot posters. The zealots will make the "web scale" arguments about any old poo poo, but don't assume everyone who is using a language or tool falls into that camp. I used to be incredibly cranky about node, and I do catalogue it's flaws, but, hey, some people are having fun. The arguments for and against software haven't really changed much, but the zealots have moved camp. If I were doing a one day demo of programming, i'd probably teach them Javascript. They will have it on their computer at home. Being able to use it in other contexts for hobby or toy projects in and of itself is not a real criticism of it. "HEY THOSE PROGRAMMERS OVER THERE ARE MAKING A DEVICE FOR FUN AND PLAY, GET EM".
|
|
#
¿
May 14, 2014 20:50
|
|
|
Zombywuf posted:So long as I don't have to maintain, use, listen to Node.js devs claim they invented callbacks or crawl the resulting web of crap I'm cool with this. So far I have been very lucky, and all of the people I meet using node have been pretty cool. I only encounter the zealots on internet comments.
|
|
#
¿
May 16, 2014 00:21
|
|
|
"but tests *are* documentation" "we don't need sysadmins"
|
|
#
¿
Jun 6, 2014 09:42
|
|
|
shrughes posted:tef how did you get on this negativity shtick? Waking up.
|
|
#
¿
Jun 6, 2014 09:56
|
|
|
TheresaJayne posted:I have been doing some coding for minecraft mods, which are usually coded by complete novices who plough through examples until their code does what they want it to. This is the problem of stricter languages, people tend to ward off errors rather than understand them. In java i've also seen people peppering "static" in front of methods to make all the compile time errors go away. Meanwhile in Python, i've seen .encode().decode().encode() to try and keep UnicodeDecodeError at bay i'm unsure of what the moral is, but it's something along the lines of "unless you explain the error well enough, people will cargo cult around the problem. if you can explain the error well enough, why can't you just do the right thing"
|
|
#
¿
Jul 8, 2014 00:27
|
|
|
See also XSA-108 
|
|
#
¿
Sep 25, 2014 04:49
|
|
|
Subjunctive posted:Is it bash-related? An embargoed Xen vuln I assumed was some escape-to-dom0 shenanigans. It's not bash related, it's just a high impact vuln coming out soon: I don't have any details beyond a) it's happening, and b) good luck with AWS this weekend
|
|
#
¿
Sep 25, 2014 04:54
|
|
|
Plorkyeran posted:Reference counting is often called garbage collection in the literature, but IMO it leads to the term GC being pretty much meaningless GC roughly means "automatic memory management performed at runtime", but doesn't precisely guarantee things beyond that, and that is OK. The words you are looking for are tracing gc. Tracing covers things like mark/sweep, copying collectors et al. The reason it's worth having both rc and tracing as garbage collection, is that is actually how it works in practice for many garbage collection systems. Reference counting and tracing are duals, too. Further reading: http://www.cs.virginia.edu/~cs415/reading/bacon-garbage.pdf
|
|
#
¿
Oct 7, 2014 02:47
|
|
|
titaniumone posted:I miss the days when this thread was primarily knowledgeable people posting obviously wrong and hilariously bad code. Someone should pin down where the transition happened from "thread contains horrors" to "thread itself is horrors" I miss the days when that joke was new
|
|
#
¿
Oct 23, 2014 19:36
|
|
|
QuarkJets posted:How does this thread generally feel about Qt? I sometimes work on a large Qt-based application, and it seems to be pretty coherent overall, but are there some good examples of horror there that I just haven't stumbled upon yet? I've had way more experience with PyQt than Qt, and on the whole, it's relatively straight forward, if not laborious. You have to manage an acylic memory graph by hand of parent and child QObjects, rather than managing ref-counts or gc. Any time you delete an object, all of the objects children are cleaned out. Although there is threads, you live in an event loop, so you also have to mash your code until it's co-operatively scheduled. The real Qt horror might be that it is a framework, not a library for c++. Everything is different, down to the data structures http://doc.qt.digia.com/qq/qq19-containers.html (no stl here mate) and there is the c++ preprocessor moc http://qt-project.org/doc/qt-4.8/moc.html too
|
|
#
¿
Nov 6, 2014 03:58
|
|
|
Doctor w-rw-rw- posted:I want to run away from people who think this way. Am I the horror? lol keep running chump
|
|
#
¿
Mar 22, 2015 18:56
|
|
|
Doctor w-rw-rw- posted:So long as there's sufficient professionalism A short play in two parts. tef: Go and work with good people and don't worry about the tech goon: BUT IF YOU *WORK* WITH GOOD PEOPLE THEN FIN
|
|
#
¿
Mar 22, 2015 18:59
|
|
|
Plorkyeran posted:It's actually hard to think of any major publicised fuckups that were the result of bad crypto, while there's countless examples from security problems at pretty much every other layer. there's the perennial 'someone implemented crypto X and reused an IV/Nonce Y', like lots of RC4 impls, or EC-DSA (sony, bitcoin) (if you re-use a random number in the bitcoin transaction crypto you sign can leak your private key) there's the "not using a secure equality function" ones where either there's a timing attack, or my favourite, where strcmp was used to check signatures, and yeah, well, null bytes broke everything hilariously badly (nintendo) or that time every debian user had very bad gpg keys because someone broke the code there's "my random number generator is poo poo" ones too, including a game show, but most of these can be handwaved as "bad crypto implementations" and not "bad crypto" for bad crypto, you have things like dvd encryption, which spawned things like DeCSS, or PURPLE/ENIGMA for some less computery variants but bad crypto rarely makes its way to bad crypto implementations, most academic stuff is built very slowly and very incrementally. there's a battery of standard tests and analysis, and crypto breaks are often theoretic before practical: there's usually enough time to move off the bad ideas before they fall apart in the end the implementation errors usually happen way before the design errors still there's good reasons we use tls 1.3 and not ssl 1.0
|
|
#
¿
Aug 27, 2016 02:50
|
|
|
ExcessBLarg! posted:Personally I view the Debian situation as a early warning that the OpenSSL project had, at best, questionable management, and one that came six years before Heartbleed really blew that open. OpenSSL may be a turd of a project but commenting out lines to make warnings go away with no oversight is beyond questionable management
|
|
#
¿
Aug 27, 2016 15:12
|
|
|
ExcessBLarg! posted:So when you get regular bug reports from angry users running Valgrind on their own programs, which complains about libssl reading from uninitialized memory, what would you do? not touch it, I'm a volunteer whos job is packaging, not forking. if people get angry about compiler warnings they should complain to openssl
|
|
#
¿
Aug 28, 2016 12:13
|
|
|
nah i'll go in and make a change in a library that impacts the security of millions of people without any oversight
|
|
#
¿
Aug 28, 2016 12:14
|
|
|
|
| # ¿ May 15, 2024 01:04 |
|
|
ExcessBLarg! posted:This is how the Debian project operates though. Many packages have some amount of patching to deal with distribution integration issues. For stable releases there's also often bug fixes done at the package level for things that upstream hasn't acknowledged, or won't support, or that needs to be backported to the version Debian is including in stable. This wasn't a feature written upstream, a feature that would be supported upstream, nor was it backporting. It was silencing errors in a compile. It was silencing errors in a tool quote:The OpenSSL bug was a big mistake, for sure, but the motivation behind it was consistent with Debian packaging procedures. No, it was a naive change made with no thought or oversight that impacted countless users and the project itself. quote:Bug or not, I think everyone (but OpenSSL) viewed it as distasteful and that OpenSSL probably just shouldn't do that. Years later the LibreSSL guys found a shitload more distasteful things that OpenSSL was doing, intentional or not, and gutted the whole thing. They at least did it the right way. Yes, OpenSSL is bad, but asking a packaging volunteer to rewrite or maintain such a specialist domain package is not the debian way. The work debian does is to make it work, make it compile, make it redistributable. This was about silencing a compiler error and a debugging tool by commenting out a line of code without any real understanding of what it did or why it was there. I wouldn't do it because I have already seen what happens countless times before when a naive developer fixes compiler warnings by shotgun until they're silent
|
|
#
¿
Aug 28, 2016 12:19
|
|