Hacker Newsnew | past | comments | ask | show | jobs | submit | dzorz's commentslogin

FWIW iSSH on iOS has good X support.


This is part of your /etc/shadow file:

    root:censored
We can still read /etc/ssh/ssh_host_rsa_key, etc.

Edit: removed hash, sorry


Saying "you can read /etc/shadow by doing X, Y, and Z" is okay -- it's a permanent record there was a flaw. Saying "here's your root password hash" is not ok; even once the flaw is fixed, that hash is still floating around out there. I'd take advantage of the edit period and remove that from your comment; it's just not cool. The OP should definitely change the root password on the box regardless.


Well one easy way to increase security would for this to stop running as root.

Please, don't ever run your application code as root. Less so when it's facing the Internet.


No problem I think I could fix it.

Can you show us how you read the content of the file. Just want to learn more


clang uses the same ABI as gcc and if you find that something is binary incompatible then it is a bug.


> approximately 60Gb of storage

Is that Gb or GB?


I use clang complete for vim. For me it is more precise than Visual Studio 2010 Intellisense (they use edg for code completion).


Here is a solution in C++. It reads K and then N numbers from stdin and then prints K largest.

The complexity of nth_element is O(N).

    #include <algorithm>
    #include <vector>
    #include <iostream>
    #include <iterator>

    using namespace std;

    int main() {
        int K;
        cin >> K;
        vector<int> numbers((istream_iterator<int>(cin)),
                            istream_iterator<int>());
        nth_element(numbers.begin(), numbers.begin() + K, numbers.end(),
                    greater<int>());
        for (int i = 0; i < K; ++i) {
            cout << numbers[i] << ' ';
        }
        cout << '\n';
    }

Input:

    5
    1 9 1 3 7 8 2 11 2 5 5 9 1 7
Output:

    7 9 9 11 8
Note: the output is not sorted.


Personally the implementation of nth_element is a much more interesting thing to see than just knowing it exists.


It's STL-implementation specific. look in your c++ kit.

in mine (osx 10.6.7, g++ 4.2.1), it's in

/usr/include/c++/4.2.1/bits/stl_algo.h

and it uses an algorithm very similar to the original article


    template<typename _RandomAccessIterator>
    inline void
    nth_element(_RandomAccessIterator __first, _RandomAccessIterator __nth,
                _RandomAccessIterator __last)
    {
      typedef typename iterator_traits<_RandomAccessIterator>::value_type _ValueType;
 
      // concept requirements
      __glibcxx_function_requires(_Mutable_RandomAccessIteratorConcept<_RandomAccessIterator>)
      __glibcxx_function_requires(_LessThanComparableConcept<_ValueType>)
      __glibcxx_requires_valid_range(__first, __nth);
      __glibcxx_requires_valid_range(__nth, __last);

      if (__first == __last || __nth == __last)
        return;

      std::__introselect(__first, __nth, __last,
                         std::__lg(__last - __first) * 2);
    }


you should look at how std::__introselect is defined (hint: its in /usr/include/c++/4.2.1/bits/stl_algo.h )


The original article uses heap to get top K numbers. It's runtime complexity is O(N*log(K)) and nth_element is O(N), so the algorithms are not similar at all.


scorchin posted the implementation of nth_element, except he forgot to look at how the gnu implementation of __introselect behaves.

If you look there, you will see it internally uses a heap.


It uses heap only as a fallback if maximum recursion depth is reached. The key difference between __introselect and the posted article is that __introselect uses pivoting to (ideally) "throw" away half of the array during each step.


Even better:

for (auto &x : vec) { }


I can't wait until I can start using this in XCode.


If you compile recent clang, it supports range based for loops.

Using https://github.com/Rip-Rip/clang_complete you can use smart context-aware completion with vim/emacs.

For example if you had this code:

vector<string> vec; for (auto &x : vec) { x

and then if you typed period (.), it would show members from std::string. I'd say it works better than Intellisense (it's very precise and you use the same parser for code completion and final compilation).


I'm too dependent on the rest of the integration with XCode to venture back into emacs land again but I'm looking forward to a rev of XCode that includes this.


> If you compile recent clang, it supports range based for loops.

Thanks for the tip, will update my copy and try it out this weekend! :D


I think this is an example where C++ really shines. The code is not much longer (44 vs 33 lines, although the output in python version is much nicer) than the python code and on my computer it is about 140x faster than python 2.7.1.


We did a distributed N-queens solver to test the Gifu Prefectural Computing Grid that an ex-job helped to develop, and that was literally all ~35 of my lines of production C code ever. (Though most of the grid turned on "graphical" mode, which both a) solved in Java and b) solved in Java at the speed of the Swing ability to update the visual board... which, after realizing, I patched to sleep frequently and run the C in the background anyway.)

This was ~5 years ago, and I don't remember the exact magnitude of the speedup on Java vs. C. I do remember it being rather less than I was expecting.


That's why you write a C-extension to CPython when you need the performance. And if you don't need the performance you stay sane by not having to write stuff in C++.


Using a library for computing the permutations I guess? I haven't touched C++ for years but I'd be surprised if the 44 lines include a permutations implementation.


next_permutation is in standard library (header algorithm).


For the curious, STL <algorithm> is one of those things that you wish you knew ages ago. Usually my code is much cleaner after I run through it and replace relevant parts of it with STL stuff.

http://www.cplusplus.com/reference/algorithm/


The optimized version of the PyPY code is around 17x faster than the first version of the Python code. That makes your C++ code 8x faster than the PyPy code, but I consider any Python code within an order of magnitude of C++ good.


140x speedup was compared to optimized python version. I've tried it vs. pypy now (version 1.5) - it is 20x faster.


Would it be possible for you to try ShedSkin on it?


I managed to compile the program using shedskin, but it throws a runtime error after it finds the first solution:

    ==== solution 1 =====
    (0, 2, 5, 7, 9, 4, 8, 1, 3, 6)
    terminate called after throwing an instance of '__shedskin__::TypeError*'
    Aborted


Ah, that's too bad... Thanks for the effort, anyway.


The proposed solution uses brute-force. How fast can you try another approach like backtracking if you're writing 30% more LOC?


Actually you can't overload && although you can overload &.


You can overload &&. You just can't make it short circuit like the default is.


Wow, that is amazing. I honestly never tried that and assumed (because of short circuiting) that it can't be overloaded.


April 1st?


Must be. I thought the link would be about Charlie Sheen.


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

Search: