Hacker News new | past | comments | ask | show | jobs | submit | archimedespi's comments login

There /is/ a modern, well-managed open-registration shell and IRC service, similar to what you're talking about, called Hashbang. You can join via https://hashbang.sh.

We're reasonably active, and we have almost 1400 registered users [edited: i was corrected by a hashbang admin as to the amount].

The ultimate purpose of hashbang is to expose more users to a traditional remote UNIX server and command line, as well as teaching people how to use it. We've created a slight barrier to entry with the intentionally obtuse signup flow, as we don't want completely non-technical users flooding the service.

I promise we won't bite :D


To join would require me to run code from the website.. or initiate a call to their API via curl?


My initial reaction was to run (and the gpg call made me curious):

    curl hashbang.sh
I was encouraged by what i saw.


Yep. You can download/verify that script by hand, or hit the endpoints yourself. They just run stuff to provision your user and files and add you to our LDAP directory.


Can confirm hitting the endpoint with curl works. Thanks for the account! :) Going to go poke around.


Or take a look at the page source.



eh, owning hardware is fun and a great learning experience


Owning is passive, it's what you do with it that matters.


tcc is blazingly fast, at least last time i used it. it's honestly fast enough that you could probably use it as an c interpreter


I do use it as interpreter on embedded boards! Preprocess/trim the headers you need, and add #!/bin/tcc -run at the top of your .C file, add a +x to it and it'll run just fine!

I love tcc, in fact I added a firmware instruction translator to 'JIT' AVR code to simavr a few weeks ago. Takes a AVR binary, translates it to C, and compiles it on the fly with libtcc to run it :-)

https://github.com/buserror/simavr/tree/jit-wip


>I love tcc, in fact I added a firmware instruction translator to 'JIT' AVR code to simavr a few weeks ago. Takes a AVR binary, translates it to C, and compiles it on the fly with libtcc to run it :-)

That is unholy, and glorious.


Ahah, thanks for that -- I thought it was pretty clever, but it's hard to explain why to someone :-)

If you look closer, you can see I've actually repurposed the main interpreter core, and uses a GNU awk (of all thing) to extract each opcode emulation 'meat', converts it to a string to and that string is used by the translator to generate the C for tcc...


Any technical reasons in particular? I'm curious.

How many passes is it doing? I suspect they aren't doing much optimization then? Maybe they patch in differences in the ASTs at the IR level and work from there?


My understanding is TCC does little to no optimization; it's intended to be used for bootstrapping.


Check and see if the Mirai code has default credentials for it, and if so, try logging in with them.


try logging in from the WAN, not the LAN. Mirai has no method of attacking lan interfaces unless a upnp rule was already set up


Mad props to you for creating that and Scanny for taking over! It's helped me automate some really nasty boring stuff that had to be done in Word.


Exactly. I see so many people complaining about the Linux kernel SLOC versus other kernels; it's an unfair comparison because no other modern kernel I know of has such a wide selection of in-tree drivers.

For instance, when I install Windows on a computer, I will often have to install additional chipset drivers (odd USB3.0 controller, motherboard chipset stuff, fan control). When I install Linux, all of that stuff works out of the box, no drivers necessary: it's rolled right into the kernel.


Making modifying stuff a felony still just slows down peoples' efforts, unless there's a reliable way of enforcing it, which is... not really possible.


Red herring. It will still be a felony and people will still go to jail over it. Most might get away with it. Might given increasing surveillance state with commercial and government partnerships. Regardless, buyers need to pick suppliers who voluntarily eliminate that risk with proper licensing unless they want to risk jail time. They should not trust anything less in a license given precedents so far.


That's already happening: KXStudio, a Linux distro for audio work, has pre-packaged Ardour binaries.


Not just specialized distros like KX, Ardour is at your fingertips in vanilla Debian and Ubuntu

- http://packages.ubuntu.com/search?searchon=names&suite=all&s...

- https://packages.debian.org/search?keywords=ardour


Note that because distros build Ardour using their stock GTK+ stack, there are a few issues with their builds that are not present in the bundles from ardour.org.

We (ardour.org) do not (and cannot) support distro-built versions of Ardour.


Why would stock GTK+ cause problems?


The most common reason is that we ship our own version of the clearlooks theme engine to ensure that we control the appearance of GTK+ widgets, and we load our own GTK2 RC file to define colors etc. for those widgets.

This leads to 2 errors, one irritating, one that prevents the program from functioning.

Irritating: GTK+ loads the system GTK theme during a call to gtk_init(). If this theme is based on clearlooks but contains declarations unknown to our (older) version of Clearlooks, you get errors.

Blocking: GTK+ loads the system GTK theme during a call to gtk_init(). If the theme file defines a "color theme", then when Ardour defines its own, GTK will block for ever, because of a bug in GTK+2. This doesn't happen if the system GTK theme has no color theme definition.

Those are the two main issues. They cannot be worked around without rebuilding the GTK+ stack so that it cannot or will not load the system GTK theme.


Thank you for explaining!

If you've contacted GTK about upstreaming your patches, what was their response? I'd be surprised if they didn't want to.


I interact regularly with GTK+ developers, and have been a regular contributor to GTK+ on OS X. They don't want our patches - they are very specialized and intended to deal with cases in Ardour that are not really a part of ordinary desktop apps. GTK+2 is now in maintainance mode anyway.


The reason someone serious about embedded development would want to buy Arduino boards is that they're convenient Atmel-architecture microcontroller boards. The ESP8266 may be "arduino compatible", but a large number of those Arduino libraries running on it had to be rewritten.

If you want convenience and ISA/peripheral-register compatibility with existing low-level Arduino code, you're locked in to atmegas unless you want to do some fun porting work ;)


The next step up was the Arduino Due, which is a low-end ARM system supported by the Arduino toolchain. But it seems to have been retired. (Now I find this out. I built something on a Due because I needed more memory and CPU speed.)


It may be retired, but Sparkfun still sells it[1].

If you're looking for other faster microcontrollers with Arduino toolchain support, there's a bunch of stuff out there. See the Wikipedia page on non-atmega Arduino-supported boards: [2].

Additionally, if you're willing to learn how to use the ARM CMSIS HAL and write raw C++, there's the STM32 series of microcontrollers. Those also support Mbed, if you want to learn that instead (it's much easier than using CMSIS with C++, it's basically the equivalent of arduino for many 32-bit ARM microcontrollers).

[1]- https://www.sparkfun.com/products/11589

[2]- https://en.wikipedia.org/wiki/List_of_Arduino_boards_and_com...


Just grab a cheap Chinese clone off of Ebay. They're pretty much completely functionally identical in my experience.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: