throwawayish

PyCharm mostly brings IDE features to the table: context-dependent auto completion, far better navigation, static analysis ("that thing doesn't seem to have this method"), refactoring (for Python mostly moving and renaming; the refactoring engine of IDEA for Java is probably the most advanced on this planet... it's ridiculously good).

Also, being built on the IDEA platform PyCharm has superb support for language injections, eg. CSS in HTML in a template language is not a problem and handled correctly (highlighting, completion, annotation etc.).

Another advantage is that the IDEA IDEs are all very similar in general usage, so if one is also working with another IDEA IDE (for me that's mainly Java and CLion) then no time learning a whole different set of shortcuts or something like that is lost.

I couldn't replace a shell with an IDE, but they do have tasks and stuff like that, might be good enough.

Regarding database, when you're using the ORM it does matter far less for development; I almost always just use SQLite. Some projects do require advanced features of postgres, and would not work with SQLite. In those cases I just start a postgres instance ad-hoc.

Personally I try to work as little with VMs as makes sense, they usually just make everything a bit harder and convoluted ("even" with Vagrant which, so far, has been a constant maintenance burden in all projects were I witnessed it's application, especially so if it's not only for Linux).

My experiences with docker range from disastrous to annoying; I try to just not use it. It's not installed on any of my systems. If I have to use it, I do that in a VM.

(I developed for some eight years on Windows, mostly C/C++, but last two years a lot of Python. At the time I wasn't aware of PyCharm, so Sublime Text "is also an editor" it was, but obviously just an editor; for development PyCharm is infinitely superior.)

You probably want to use PyCharm. It's a great IDE, and pretty much just works.

Personally I find the various CLI tools typically found on a BSD or Linux rather enticing for development, but many people do without that.

Apart from that I'm not sure what you could mean / what your issues are. Specify?

I correct you. You are wrong.

If they upgrade to all in-memory databases their full-table scans will run faster

/s

A transaction log needs to be cleaned up, which takes time. You might amortize cleanup over many small objects.

> but it does work for eg some file systems---which are also a type of database

No mainstream FS uses the txn log as a primary store. The log(s) are only around for active writes to metadata, as soon as the second write is out the spot in the log can/will be reused. Similar to the clean up case FSes try to batch as many ops as they fit into their log(s) before flushing the transaction.

Apart from the CoW herd (ZFS, btrfs, HAMMER) most FSes either can't or won't journal data by default anyway. -- Which is a fairly often overlooked point, many people seem to assume that a journaling FS means that everything, include their application data, is journaled, which isn't just wrong, but can also be a rather dangerous assumption; depending on application.

You're correct, I'm not referring to SSH specifically, but speaking generally about the application of asymmetric crypto. The quote in GP, and GP's question, both seemed to indicate this broader context to me.

No, not at all.

What you do notice is using ciphers that are apt for the machine. If both ends are modern x86, for example, then you'd want to use aes256-gcm@openssh.com or aes128-gcm@openssh.com for best performance. Otherwise stick to chacha20-poly1305@openssh.com, which is the default of recent versions.

(Also, obviously RSA does not do DH or a similar mechanism for establishing a shared secret. The workaround is to generate ephemeral keys and sign their public keys with RSA, then generating a shared secret from the ephemeral keys. This is what eg. TLS does in principle, but also shows that RSA still has it's uses: RSA signatures for long-term proofs of identity, ECC for forward-secure communication.)

There are also other caveats. Eg. EC keys tend to be tiny, just like symmetric keys, so one can much more easily distribute them through eg. QR codes, or even read them out loud. RSA keys, not so much.

If ECC fits the application well then using eg. Curve25519-based crypto over RSA or other EC is pretty much a no-brainer: it's, by a large margin, the asymmetric crypto systems with the fewest caveats both in implementation and application, and it's also very fast for any operation.

Ed25519 keys are short... someone with a good memory should be able to memorize their private key (it's just 32 bytes).

It's just such a moot point.

If you have relevant data, then you simply don't cross borders with a device containing such data (or with a computer at all). This is just common sense. This "plausible deniable encryption at the border" nonsense is just a cryptonerds imagination.

> make them plug it into the copier anyways.

I heard USB is a finicky thing, rather hard to implement correctly.

I wonder how many of these copier devices (-- are these dedicated DSM-like units? Probably embedded/outdated Linux then!) were already infected and grep copied contents for relevant data.

> are very good free alternatives which can be managed also by non-technical people with zero telecom experience.

Are you kidding me?

I run my own PBX (would count as a SMB from a user/call count perspective). It doesn't run on any open source software, because all FOSS PBXes I looked at where ridiculously hard to configure. FreePBX is a great example there.

Anyhow, I mainly looked into AskoziaPBX and Vodia after that.

Askozia terminated their "diet" version and costs 250+ € (only one variant is offered).

Vodia has a free version (5 extensions, which is exactly enough), and has a more granular licensing scheme. I didn't fully setup Askozia testing, but it looked quite nice. Vodia was also reasonably easy to configure (about 1-2 days initial setup and after a couple weeks I got all the kinks fixed).

New potential contributors to a kernel that are deterred by not having a ruby-on-rails web GUI wouldn't have contributed anything anyway. (IOW there are none that fit you description).

Isn't the time needed for triage and review - since most PRs will be package updates - much lower than in most other projects?

I very much agree.

Much of this is in the area of management (and thus social - building a culture around a project), and has relatively little to do with tooling per se.

Contributing by patches is even simpler, since you don't even need a place to host your repo. Instead you literally do "git format-patch some_base_ref" and get a bunch of files you mail someone.

It doesn't get any simpler...

> Yeah, I realize a lot of devs have already have their own setups that work extremely well for them. Unfortunately anytime you transition to a new tool you're obviously going to break _someone's_ workflow.

So don't.

Do you have a single compelling issue why they should switch?

> By that reasoning though, isn't almost every problem in open source projects a "non-issue", because you can always just fork and do things your way?

Yes. Because that's true. Either you have a good point and manage to convince people in the project, or you have to fork.

Writing irrelevant comments on some news site is not going to convince anyone to spend a combined hundreds to thousands of man-hours work (at the very least) to move kernel development to GitHub or whatever platform you like.

Also notice how you are ranting about tooling in a project you're not contributing to, while the submission here is about something entirely different -- and written by a contributor.

Late 2012: https://github.com/bundestag/gesetze

The idea that law is a kind of code (in the CS sense) seemed like a pretty common idea to me... I remember various jokes revolving around that. I doubt anyone wrote those down, though ;)

> [1] MIT (Computer Science & Artificial Intelligence Laboratory) / Harvard University (HLS, Berkman Center for Internet & Society) bearing this philosophy out in 2014.

The notion is far older than that.

Because the author wrote this as a fun exercise in what seems to be one of his favourite languages for testing a library he wrote (libpy)?

Comments today....

In the case of Linux there's actually a (specially renamed) instance of a tmpfs mounted on /. Usually the real system root is mounted over that.

A GPU isn't really comparable to the modern CPU sitting beside it, since it lacks many of the CPUs features, eg. virtual addressing, while in the other instances mentioned the processors were pretty much the same, feature-wise.

GPUs do, like most peripherals, contain additional CPUs that control them -- in the case of GPUs these are proprietary architectures specifically designed just for scheduling and sequencing tasks on the GPU and are said to be quite potent, for a device control processor.

Similarly hard drives had multi-core MIPS and ARM processors for quite a while (ditto for SSDs, in both cases they are ASICs, the actual data juggling isn't done by the CPU cores), and they even have quite a bit of RAM -- the cache -- that they'd normally share with the DMA engine, plus some of their own...

The control processors in most other peripherals are usually much weaker, though. They're pretty much just microcontrollers.

Ah right, I was thinking about the 8250 indeed. It made click when you mentioned their curious "multi-processor" arrangement.

And VAIO is a kinda poorly designed logo; you only know it's supposed to say VAIO because someone told you...

> Also amusing that the STM32 supporting CPU has far more power than the main Z80 CPU.

I believe some Commodore drive already had two processors identical to the main processor of the computer -- effectively giving the drive more processing power than the actual computer :)

Not hard. You can support 3 and 2 in the same file without much hassle.

Practical example: https://github.com/zopefoundation/BTrees/blob/master/BTrees/... https://github.com/zopefoundation/BTrees/blob/master/BTrees/...

There are a couple #if PY3K, but not much, really.

I ported a bunch of extension modules, total a couple thousand LOC, and it was pretty much a matter of reading the docs (see guide at https://docs.python.org/3/howto/cporting.html ) and adding a few #ifs. Total time maybe an hour or two.

That's, like I said, my general observation from reading like a dozen comments from you just on this item. You're literally bickering on about this in pretty much every Python-related item on HN. It is very hard not to notice your comments if one frequents this site. I stand by my comment above.