ejr

Ah yes, involving Worf in "Looking for ParMach in all the wrong places".

Your mother is an excellent judge of sci-fi character.

I've seen many arguments that the role of Sisko was heavy handed in many ways and there are some truth to that, but with the exception of a few, any episode featuring the brilliant Avery Brooks is likely to be a good one.

I enjoyed "Magnificient Ferengi" in particular. An all Ferengi episode that featured virtually every prominent character of the race except the Grand Nagus.

Edit: It seems even on the list, there is Season 3, "The House of Quark"

The difference between a haphazard device driver, a bootloader by a ragtag group of hackers and a space capsule is national pride and lives at stake. ;-)

We should encourage software to be written as if it will one day fly in space.

Seems to have been part of the user interface

https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Softw...

  A set of interrupt-driven user interface routines called Pinball provided keyboard and 
  display services for the jobs and tasks running on the AGC. A rich set of user-accessible 
  routines were provided to let the operator (astronaut) display the contents of various 
  memory locations in octal or decimal in groups of 1, 2, or 3 registers at a time. 
  Monitor routines were provided so the operator could initiate a task to 
  periodically redisplay the contents of certain memory locations. Jobs could be 
  initiated. The Pinball routines performed the (very rough) equivalent of the 
  UNIX shell.

That's not entirely fair. I mean it can be a massive time-suck of pedantry at times, but I've learned a great deal of very useful things about work and life here from articles and comments.

Humans are weird creatures; we achieve productivity in very unexpected and often unintended ways.

But this is what concerns me as well. Yes, the effect is significantly - several orders of magnitude - greater than what the theory predicted, however there's no reassurance that it's outside local noise in the lab. "Gravity probe B" was extraordinarily sensitive and safely outside local noise.

I suppose the next step in testing this effect would really be to try it in space.

I'm cautiously optimistic, but let's be a bit more reserved on this until we see it properly peer reviewed. This area is ripe for pathological science and a myriad errors induced by human factors.

Hopefully other labs around the world will be able to duplicate the experiment soon. We'll see if the results are as well.

I'm not speaking to the validity of whether or not DNSSEC is actually a good idea. Your contention is that it's not. But saying the equivalent of "no one uses it" is demonstrably false.

  >Virtually no important services on the Internet rely on DNSSEC.

Don't know about "important", but many governments including the U.S. consider it important enough to deploy:

https://en.wikipedia.org/wiki/DNSSEC#Deployment http://fedv6-deployment.antd.nist.gov/

I got the same. It may mean we passed the base level in the C languages since the syntax matches.

That's very cool! They really are following the hacker spirit; the enthusiasm they have for their work, the try-and-see discovery of capabilities and the joy they have in sharing what they've done. It's very refreshing.

This is one of the most fascinating groups I've seen in quite a long time. Check out their YouTube channel too where they show details on the turbopump https://www.youtube.com/watch?v=p6BC1QfA0Ug

There are lots of samples for PHP, but you don't need to study that. As d33n suggests, there are examples that already use flat files as a database and you can browse Github for code examples.

Our forum was setup so that one thread = one HTML file. Any new replies to the thread were appended to the bottom of the file right before the footer. The added benefit of this is that it was very quick to read new posts as there was no processing taking place after the post is created.

Ex: If a new thread is being created, it will generate an ID, say 140585637400000000. Now this gets translated into a path : /140/585/637/400/000000.html and a file is created there.

The body of the new thread is added to the HTML file. Any subsequent replies are added to that same file right below the previous one.

So when a visitor requests example.com/topic/140585637400000000, the script takes the last part, turns into a file path, adds a template - which has the reply form with that ID - and sends it to the user. No additional processing needed. When a new reply is made, the script builds the path again and adds it to the bottom of the same HTML file. And so on...

I think your biggest hurdle is the initial planning. Try to carefully plan this out as much as you can, but obviously you won't know what future circumstances will bring. If you build it in such a way so that the storage mechanism doesn't need to change much or at all, you should be most of the way there.

Edit: Maybe I can convince the admin to publish some of the source. You're not the only one to be interested in something similar and I think there's a real demand for lo-fi community software.

You can run a community of sorts, but the feature list will be sparse. The only viable system sans-database that comes to mind is plain-text.

I'm a member of a forum that had an old system in the beginning that used plain text "database" for a very long time. Performance was fairly reasonable at 5000 visitors per day, if the daily hit counter was to be trusted. They since moved it to SQLite, which is very reliable in its own right, and now it's Postgres. It was only now that we got searching as a "feature".

The system was written originally in PHP 4.x, but they did move it to 5.x. I'm not sure what version they use now. I do know they were running ancient hardware and was up solely due to the charity of the admin.

I think there was an index file that stores new topic summaries, as there was no field for titles, when they were created.

They used microtime() as the ID, but the topics were stored by splitting it to 3 digit directories.

Seconds as 1234567890 and decimal 0.12345618 were combined to create /123/456/789/012/345618.html

There's no registration system or other way to identify the user so I believe the posts were separated by some kind of entry separator in a single file.

I think the pagination system created an array of sequential IDs and checked to see if files existed in those directories. There were no numbered links for pagination, only next/previous and if you reached the end, the next page would be blank.

There's no reason you should ever get laughed at for being curious.

This looks to be very good. One tiny, and I do mean tiny, wish is that the code follows BSD/KNF style. I know that's all down to preference anyway, but it does make things easier to absorb.

It's very good text-to-speech synthesis. The voice sounds similar to "Mike" from http://www.naturalreaders.com But I cannot be certain.

Mods, please change the article URL to this.

Same here on multiple browsers. In case you're interested in what it's running : http://toolbar.netcraft.com/site_report?url=http://example.c...

This might seem simplistic, but couldn't this problem be solved with a "related" list?

It's been many moons since I've been to Digg, but it had a notification if you're submitting a post with a similar title/URL. While we're discussing it, it may not hurt to have a "previous discussion" list either.

Opinions, information other relevant factors can change over time, so it may not be so bad to revisit a topic.

That's interesting. I hope it sees more widespread adoption by browser vendors and the recent security disclosures will hopefully help to tip implementation in that direction.

Which is why I suggested Suhoshin above: https://news.ycombinator.com/item?id=8056907 And on a number of replies advocated for certain precautions in addition to the much maligned disable_functions list.

I'm not going to visit this thread any longer as it's getting to be an exhausting exercise of having to wade through snark and general malaise. I'm reminded, once again, why I waited so long before making a single post on this forum.

I wish there was an alternative to the CA system we have now. I'm part of a private forum with a self-signed cert and while initially there was some hesitation to it, most members have added it to their browser exceptions.

iPhone and Kindle, but my Android seems to get through.

There's Suhosin which does a great deal to lockdown the core and has largely limited functions to the essentials http://www.suhosin.org/stories/index.html

On debian, I've used : apt-get install php5-suhosin

My recommendation to use OpenBSD, while a bit of toung-in-cheek, is actually because the PHP (5.4.24 as of the 5.5 OS release) is installed with the patch and Nginx is also chrooted.

If the API uses HTTP, it's fairly straightforward. PHP has had streams available for quite some time : https://php.net/manual/en/stream.contexts.php

Many shared hosts often don't have cURL and so stream_create_context is an alternative https://php.net/manual/en/function.stream-context-create.php

There's even a REST helper from 2006/2010 : http://www.wezfurlong.org/blog/2006/nov/http-post-from-php-w...

I've addressed these concerns and more in my subsequent replies. Your tone suggests my efforts to reply here will be wasted. Have a nice day.

The dropper has to be present on the server somehow to get the rest of the payload so you have to have uploaded it there, allowed a user to upload it[1] or be in some way included by a malformed script or some other existing vulnerability. This includes a very large scope of potential access points.

Ex: This particular sample was in PHP so Wordpress comes to mind. Plugins in particular are notorious for poor programming practices that allow such file inclusions.

[1] Disallowing by extension doesn't always work as some filters allow img.php.png or img.png.php. Besides this, an image can skip the .php altogether and still be executed as a PHP script

Ex: https://security.stackexchange.com/a/32970 and https://security.stackexchange.com/a/32969

Note however, this doesn't just apply to PHP. There are potential vectors in Perl, Python and Ruby when adequate measures are not taken to sanitise user input and filter arbitrary uploads.

Python and PHP need not be adversaries is my point. Long running, ex. polling, bots, scrapers etc... can be better dealt with in Python as it has dedicated tools and frameworks for those purposes. Backend applications that don't directly deal with the web front allow for better compartmentalisation of priorities and privileges.

Think of it this way; if a layer of your stack has the capability to destroy a system, it's probably best left speaking to another layer that actually speaks to a user.

PHP for web and Python for backend is not a foreign concept and so it makes little sense to apply one hammer to all variety of nails.