P2P-sharing would be a really great solution to this from the malware developer's point of view. I don't harbor any ill-will towards malware devs, especially not when they're going after windoze machines :^)
But yeah, the curl website could really come up with a lot of data, so it seems like a very immature solution to what is really a critical component of the app to just blindly reach out for some predefined url. It'd be way smarter to run a CC machine somewhere and start pairing some peers. curl is somewhat small, right?
I think they'll probably just keep renaming the file for now, and updating the URL. It'll just be cat and mouse, and newer versions ship with it, so there's really no point for the curl maintainers to be wasting too much time on it since it's a limited-time issue that will more than likely sort itself out later.
Yeah! Them people that don't share our hobbies and choices can get fucked, right? I mean transitioning to linux is so easy and relearning a new ecosystem so painless. Them scam victims deserve whats coming for them!
I also agree that malware devs are dumb. Instead of using that curl download in a way they know works, they could just add a p2p module to their malware, open up a few ports on infected machines and hide all that from av. Easy right? I mean them archive urls change all the time! And updating that via the cc is just too unelegant!
You are the type of person I was hoping not to encounter!
The kool-aid drinkers.
I don't like Clojure or ClojureScript. They are both awful by virtue of the platform they exist on. I would like very much if Clojure had a core lisp KLambda, because I could abstract Clojure onto a platform that wasn't terrible.
Rich is a guy who (whether consciously or otherwise) hated writing Java and decided that functional programming worked, and that Lisp did too. Clojure is a strange abomination from the points of view of those in the pure-functional family, and those from the paren-dimension, but I find that Clojure code reads easily, and comes off far more expressive than that of Python or Ruby or other so-called expressive languages.
When someone who uses the JVM tells me that something I know to be true is 'fundamentally flawed' I become fearful for myself, that I might drown in irony.
To anticipate the objection, no, this hasn't a fig to do with political correctness. It's about trying to preserve HN as a place where people want to come for substantive discussion. I'm sure many of us agree with your views on Lisp; that doesn't mean you get to be an arsonist.
Q: Is Clojure bootstrapped on something other than JS or JVM or CLR?
A: No, and don't waste your time on this talk if you already have watched any of Rich Hickey's talks, this is an ego-stroke at best that introduces no new solutions to any problems. It's an hour and a half of 'Hey look what clojure can do', and 'Gee, our documentation isn't great'.
Maybe someday Clojure will have something like the Shen project has with KLambda. A tight, core language implementable in any language, and a language library built on top of that core language, agnostic of the implementation it's derived on.
If Clojure had gone this route, we could basically have Clojure on any platform capable of parsing and modifying S-Expressions.
Actually, from someone who has been writing Clojure for a living for the past 5 years or so: I'm very glad Clojure did not take that route.
The idea that you can have a language which is portable/reimplementable on any platform is fundamentally flawed. You can't.
It is because of the fact that Clojure and ClojureScript are not really exactly the same language, and are implemented in very different ways from each other, that we can take advantage of many platform-specific features that would otherwise be abstracted.
> The idea that you can have a language which is portable/reimplementable on any platform is fundamentally flawed. You can't.
If you can't implement C on a platform, I think you're in some pretty strange territory and you're probably having to invent your own language to match the platform.
You couldn't have given a better example. C as a language doesn't have a standard library, with the standard library being Win32, or whatever comes on POSIX/Unix systems these days. You even get a different libc on Android, which isn't glibc, so with its own quirks and bugs. Win32 doesn't do fork and I/O is very different. And on embedded systems you're going to work with a C subset. And each compiler has special extensions.
In other words what you call C is actually very different from platform to platform, people solving that with a crap load of ifdef statements.
No, what I call C is the same on every platform. Otherwise, all those "crap load of ifdef statements" wouldn't work. What is called the C standard library on each platform is different, because as you said C itself does not define a standard library. So yes, I did pick my example very appropriately.
What if the platforms are the JVM and Javascript, and you are chosing those platforms because of their extensive infrastructure and libraries?
It is possible to implement C faithfully on these platforms, including all of C's weirdness like pointer-arithmetic and unsafe casting. But you'd end up with something that departs far from the platform's runtime model and calling conventions.
Now, if what you really meant was more along the lines of "can I faithfully cross-compile C to Java bytecode", the answer would be "not without a layer of abstraction".
"The idea that you can have a language which is portable/reimplementable on any platform is fundamentally flawed. You can't."
Can you elaborate? Shouldn't VM just standardize EVERYTHING on the language level? Can you give specific examples when language NEED to be aware of the hardware?
You always need to be aware of the hardware/target-platform. Some examples:
1. Bioinformatics
2. Data storage
3. Any soft real-time application
4. Any kind of constraint search with simulated annealing through large spaces
5. Operating systems
6. Compilers
7. Image recognition/analysis
8. Rendering
9. Basically any application where the user expects a responsive result
You ignore performance at your peril. The reason why we have super-fast computers and software with loading screens is because of this thinking.
If you do have a legitimate reason to run on a VM you should be aware of the burden its abstractions places on your ability to reason about the performance and costs your program will incur.
Sure, you can standardize everything. Just get the most common denominator of all your supported platforms and abstract that away. Problem is, it won't be useful for anything practical.
Someone mentioned C, and it's a good example. C is different on every platform. If your C code interacts with the world in any way, you won't write the same code. Libraries will be totally different, not to mention that pointer sizes are different, byte ordering is different, and even your lowly int might betray you. The reason why C is so practical and widely used is exactly because it doesn't try to force a platform abstraction on you.
> The idea that you can have a language which is portable/reimplementable on any platform is fundamentally flawed. You can't.
True, but some people push the limit of what you can do much farther than others. Take a look at what the ceylon team is doing, to see what you can do if you plan for it from the beginning.
I haven't worked with it too much, but being on the JVM is one of the things I like about Clojure. The JVM has a huge standard library, but I don't really like Java so Clojure gives me a way to use all that existing code in a language I enjoy writing. There are definitely some downsides to the canonical implementation being on the JVM, but any move away from that is going to end up "wasting" a lot of effort reimplementing all of that library and I just don't see it being worth it, at least at this point.
I'm excited about the ClojureScript-in-ClojureScript work - apparently it will soon be true that you can run ClojureScript on top of any JavaScript environment, including node. That's very close to Clojure on anything!
Doubtful. I'm sure they'll ban whomever they are able to identify, but there are most definitely other reasons this suit will develop into a storm. Fiverr threatens Amazon's business model, and Amazon will do anything to keep turning a profit.
I'll be EXTREMELY shocked if Amazon drops more than just a couple of these suits, they're out to prove a point that THEY run the market, and not Fiverr.
You may be right about Amazon's intent, I don't know. But Fiverr is no threat to Amazon's business model. Even if Fiverr's purpose were fake reviews (it isn't), reviews aren't a key component of Amazon's business model in the first place. And there are plenty of cheaper, faster, and less likely to create bad PR ways Amazon could put a stop to fake reviews if they really felt threatened by them. For starters, it would be very simple to (a) only allow verified purchase reviews if the user bought the product via Amazon, and (b) make sure all verified purchase reviews are shown before any others (or larger, or not greyed out, etc., etc.). The fact that Amazon hasn't done these things tells me they consider fake reviews a nuisance, not a threat.
You think a quarter-trillion dollary company hasn't thought about letting users freelance on top of the Amzn distribution model? Don't make me laugh! They want to play 'good guy' here because they can get easier data collection if they don't have to verify customers for reviews, and it allows for customer conversion if someone sees that the product is in fact what they want from reading the reviews. They want the identities for that very reason of removing who could be faking it, but I think you're absolutely right that they don't feel threatened by the reviews themselves.
Fiverr is the threat here, and that's a good thing. Either way, I'm buying from Jet from now on.
Could something like this be contained in a box, so that each of the sides has these on it?
That way instead of just working laterally, and from the bottom, things could be done from multiple angles. For example, solving a rubiks cube via machine typically involves at least three axes and servos, but with a machine like this that operated on three axes, I imagine a more power efficient method could be developed.
This is really cool technology, I love how simple it is in design, yet it evokes all kinds of ideas in the mind.
I mean, say we put through a few patches and started generating primes more often. Then there big-ass special purpose prime machine becomes an order of magnitude less-effective, right?
I think the best way to defend against these one-to-many attacks is to spread out the cost of decrypting large quantities of data. If we all had our own keys, even if they weren't as strong as one single key that everyone used, that much more work has to be done to decrypt data for a group of users.
I know nothing about crypto, but a layman can hear about these implementation architectures and immediately realize what's wrong with it all.
The problem is that there needs to be an agreed upon key that each of the parties knows before-hand. But yes, there are definitely viable ways to generate new ones or implement new, safer, standards. Alternatively, a much larger prime can be used. Also, the Diffie-Hellman protocol is a well known one that many many security researchers, programmers, and students have looked at. The flaws are not obvious, as it's initially unclear how "cracking" a large prime would work.
I am so excited! I have been waiting to have an excuse to spend some time with BSD, Lua kernel scripting is definitely going to be something I mess with this weekend.
The manpages for lua(4) and luactl(8) may be of help.
lua(4) is the device driver which allows you manage Lua states in the kernel through an ioctl interface. With luactl(8) you can create and destroy states, load and execute scripts, and require modules.
Example:
1. Load lua(4) driver
modload lua
2. Create a Lua state in the kernel
luactl create s0
3. Load and execute a script named hello.lua
luactl load s0 ./hello.lua
4. dmesg
A Lua state is created empty. In order to load the standard libs (base, string, table, ...) into that state you'd need to do a luaL_openlibs(). Even though the libs are compiled into lua(4), you can't easily load them with luactl. [1] is a patch that adds a 'openlibs' command to luactl. After you apply it and recompile luactl, you can do that:
luactl openlibs s0
Btw, we've ported Lua test suite to the NetBSD kernel in this year's GSoC. Part of the work was on porting parts of the standard libraries which were not available in kernel Lua (e.g., os, io, math). Take a look at [2].
Let me know if you need any help. My email address is my HN username at gmail.com
Before Groovy was Beanshell, which was Groovy's inspiration. And of course Groovy's creator, James Strachan, did say if he'd known about Scala at the time, he'd never have created Groovy. And Groovy's quite weighty itself, have you seen its Antlr grammar file?
But yeah, the curl website could really come up with a lot of data, so it seems like a very immature solution to what is really a critical component of the app to just blindly reach out for some predefined url. It'd be way smarter to run a CC machine somewhere and start pairing some peers. curl is somewhat small, right?
I think they'll probably just keep renaming the file for now, and updating the URL. It'll just be cat and mouse, and newer versions ship with it, so there's really no point for the curl maintainers to be wasting too much time on it since it's a limited-time issue that will more than likely sort itself out later.