PythonicAlpha

Thank you for your information! That would be really a fine feature. I love Debian for its stability (as it is said ... I just lack time, to compare myself) but the administration tools are still a black box for me and I have the feeling, that they could need a brush-up.

  I'm sure it can be golfed further with the illegal opcodes that I am not familiar with.

Possible. But not necessarily. Long time ago I reviewed the many illegal opcodes of the 6502. Many are simply doing nothing and most of them are not useful at all. The few that are useful give little benefits, because they can be used in very very few situations. I finally did not use them, since I don't wanted to break compatibility with 6502 successors (which where very few, finally).

I must acknowledge, that I don't have so much administration knowledge as you have. I come more from the development corner. And I really "hate" that stuff. I also have to say, that what you write is probable right. But I think, there are some people like me, that have one or two servers for some projects running (and I know even people, that have websites or even servers running with even less knowledge) who just want that the stuff works and don't have time or ambition to optimize things.

Do you know, if this rollback stuff is also available for Debian based systems? Sounds pretty good. I regret, I don't know yum, it is for RPM-based systems, I know, but the last systems I used where all Ubuntu and Debian.

For people with >2 servers, that might be the right solution, but for the others, scripting deployment might be just more overhead.

I also can not recommend the "frequent upgrades" model.

When systems would be more stable and less problems would occur at updates, this would be right. But the reality is simply different. My experience is, that on many updates there are surprises:

- software that once was good, just has gone garbage since the last version

- some problems with not so common software combinations that was not found from package maintainers

- some device drivers that do not cooperate

- desktop environments that do no longer support some options as before or just have gone bad

- legacy data is not supported by newer application versions or some subtle problems with this data occur ...

- ....

Also, when upgrades would be possible without hassle and troubles, that model could work -- but it just is not. For example: I wanted to install a newer Ubuntu version on my hosted server. But the automatic upgrade process explicitly says, that it should not be done via a remote session. So for a hosted system, I have to fall back to a complete new install (backup data, fresh install, complete new configuration, re-install backed up data).

Also, when you get into trouble, it is not possible to easily go back to the last stable version (in this situation, virtualized systems are very useful).

In such a case, it is clear, that I don't want to give up my life to always have the newest stuff on my server.

I regret, that OpenBSD is not for me (unless OpenBSD does never suffer from those troubles).

I also stumbled over this "feature":

I edited one note and pressed "library" instead of the floppy, since there appeared some text, that said, it was autosaved .... But when I got to the library, the note was in the same condition as before the edit.

So, according this test, "auto save" does not work (correctly) IMHO.

I am not familiar with Evernote and the other tools -- but when I try to test Paperwork, I got stuck:

How can I create a note? When I press "New note" simply nothing happens. I can take no notes, add no documents -- nothing. Just two big white areas that are plainly saying and doing nothing.

Ok, I found the problem: When I use "German" interface language, it does not work. With English interface language there comes a new dialog. Guess, this is a bug.

It seems, in some countries, people are just waiting for the next terrorist act to bring out new ways to undermine the principles of democracy.

Without privacy and the possibility to express one self without fear, democracy is not possible. We create monstrous systems that become bigger and bigger and destroy democracy from within.

One important reason for the success of C was the library. One of the reasons for the success of Python is the big library and the plenty of add-on modules.

But on the UI side, Python has its weak point. The other problem today is the trouble with the migration from Py2->Py3. But on the long run, the UI problem can be even more trouble. Python is still a good language on the server side, even when PHP was faster and still has a bigger market share.

Still, I think, that Japan directly attacked the US at Pearl Harbor made a big difference. Germany was also seen as having a bad regime with war criminals, but they started the war with the US not with such a carnage. So, I think politicians and parts of the US people in this time saw Japan as the worse "beast".

Of course, every development also has its counter-development -- specially when a big court gives new guidelines. Everybody (the examiners, people who think about the system and judges) can see, that the system is overstretched. So a reaction was very much necessary.

But there are strong forces, that are pulling the system into the wrong direction. Big corporations, patent lawyers and investors want the overstretched system, because it is good for their profit.

It is good for dinosaur corporations that want to defend their "claim" against smaller and more agile competitors.

Ok, I did not dive to much in the detail.

But I don't think, that repeated rejections would make the patent office happier. First of all, they would create much (political) pressure from the big corporations and second if they reject to much, the number of patent applications would decrease.

Third, they would cash in less maintenance fees.

The US patent office is paid by the patents it grants. So this idea will never be realized ...

Also the numbers of patents are presented every year to prove, how grand the nation is. Nobody wants to spoil that.

(BTW: That would be a real patent reform)

The question is: Will it (only) hit the real problem makers?

For me, patent trolls are only a symptom and not the real problem. Patent trolls are a symptom of an overstretched patent system, where everybody (with enough money) can patent anything (also stupid and trivial stuff).

Where 50 years ago, one patent was made, 10 or 100 patents are made to secure any detail of the "invention". And many, many patents are made, that would have not have the smallest chance of been patented.

Remember: The patent application for the Z3 (one of the first computers) was denied. [1]

The problem is: How to distinguish small inventors (for which the patent system in former days should give security) which do not have the capital to produce their invention from so called "patent trolls". My fear is, that the legislation will fail to make a good enough distinction.

For big corporations it is a good thing to redirect the public agenda from the patent system to the smaller topic of "patent trolls". Big corporations that make many thousands patents a year, are also a part of the problem and not "patent trolls" alone.

[1] http://portal.unesco.org/ci/en/file_download.php/875fd251dc5... See Abstract

There is also an other reason for not wasting "a single byte":

Branches are the only Jumps with condition. So, when you have a far destination that is more than 127 bytes away, you have to do that:

   want to do:
            BCS far_dest

   Have to do:
            BCC no_jump
            JMP far_dest
    no_jmp: ...

So, when you wasted to many "single bytes", you may end up up adding 3 Bytes and at least 3 cycles to your conditional jumps.

Ok, on 6502, you might be right (if your numbers are correct). But the 3 cycles might have been, because a decision according flags had to be made -- so a newer processor could have made an unconditional branch faster.

That is correct. Also, when you see, how much space was available. On Commodore, the Basic had to fit into 8k+ (together with the "Kernel" it had 16k of Rom and the Kernel needed ~7k) -- so space was really scarce -- a bigger ROM would have made the computers more costly.

That is right. The JMP is a jump, because it takes a full 16bit address. Branches where all relative (-128 .. +127 bytes relative to current PC). I am not sure, but it also is very probable, that branches are faster -- at least the processor had to fetch one byte less. That should be the other reason, that newer processors had the unconditional versions.

That was one hacking thing in these days: finding flags that are guaranteed to be set or cleared to use as condition for a branch instruction. I remember, that I always tried to avoid JMPs.

Some days ago, we only had 64kb main memory to squeeze our applications into ... that was also a great experience. The old times come back?? ;)

That is the only valid response to such an attack. With different responses, the terrorists win.

I think, it was just one top feature of the first standard C library. It made printing a lot easier. In standard Pascal or Modula 2, you still had to print every single data type with its own special "WriteX" statement. Even there was a distinction between "WriteString" and "WriteLine", the second wrote a string and added a Newline after it (I am not sure in the moment, if it really took a string or just wrote the NL). In printing to screen, some languages of those days where really spartan.

Yes, Henry Ford also was one of the big business man in history, that realized that also his well-being was depending of the well-being of his workers. But since that time, the shareholder value has taken over the government.

(Edit: Tried to correct my bad English, sorry!)

I liked Modula 2 much more than Pascal or C. (for those, that don't know it:) Modula 2 was the successor of Pascal from Niklaus Wirth. It had cleaner syntax and many other good features. Its successor, Oberon, was object oriented. [1]

But the culprit (and that belongs to all Pascal descendants, as it seems (at least until Modula 2)) was, that the libraries where not very helpful. The standard libraries for Pascal (not the extended ones from Borland Pascal or others) and from Modula 2 where a pain to work with and did not cover the developer needs. I guess, that was one reason for the downfall of Pascal -- some niches (eg. Borland Pascal) where successful, but they lacked the broad covering. C had it all: A syntax, that was popular by many, because it could be typed fast (not everybody will agree that it is an advantage) and a library that covered everything you needed. Also with printf it had a neat solution (according to that time) for a problem, that was really cumbersome to deal with in Pascal or Modula 2. Also you could write C code for one machine and port it rather easily to another, because the libraries had nearly the same API.

I account some good part of the initial success of C to the standard C library. After that it was just a question of publicity.

Also one mistake of Wirth might have been, that he took different names for his languages. I guess, the languages would have done a little better, if he called it Pascal2 or Pascal++ and after that Pascal++15 or so .... but that is the other problem: Good engineers are usually bad marketeers.

[1] http://en.wikipedia.org/wiki/Modula-2

The "one size fits it all" notion of malloc/free/realloc is just wrong. When you want optimal allocation performance, you can't get around specialized allocators of various sorts for various needs.

Yes, I implied that. But of course, when you do so, you create an own "flavor" of Python, that will not be understandable for others.

More discussion would really help here.

I think, in some cases, spaced allocation will come (nearly) for free, since with 64bit addressing, there is enough space reserve (most processors can only use a fraction of this space as physical RAM). The other point is, that with the use of MMUs and a proper spacing (regarding the MMUs page size), the gaps come nearly "for free".

But I think, that needs very careful thought, to make it right and not unnecessarily introduce new tradeoffs, as you very talking about.

What you should not do, is use such spacing for small allocations. An other point would be, to inform the allocator, that it is likely/unlikely that a reallocation will be done ... in most cases, such information is available.

Trying to avoid self in Python is just no good idea. You just break one basic convention of Python just because you don't like one thing in Python.

I would recommend to the author of the article one of those things:

  (a) either find a programming language, where you like everything (I guess, unlikely)

  (b) or write your own programming language

After some years in the business, I have learnt, that every programming language has its own "hell".

Some hells are hotter, some are relatively mild. When you try to avoid every hell, you will end up writing your own programming language ... and be very lonely for the rest of your computer-life.

Pythons oddities are one of the mildest I have found yet, IMHO.

That is right. But till now, I could use a simple Google acount (not G+) to login for example at Stackoverflow.com.

In future the button will change from "G"-Login to "G+"-Login. As somebody else stated, Google said, that a normal Google account will suffice in the future, but alone the wording and the new button will alienate people.

From this Link:

https://developers.google.com/accounts/docs/OpenID#shutdown-...

and from common sense.

BTW: Maybe you should also read my full post, before answering.

   The final problem is that not many people will write a full implementation of
   it other than the big players like mozilla itself or Google or Microsoft.
   And the latter two don't have a ton of incentive to do so.

When I see such a proliferation (I looked at one architecture image of OpenID.connect and was shocked) than I am reminded of SOAP and I again think, that one reason might be, to hold smaller players at bay -- and to give the bigger players an advantage. For Facebook, Amazon or an other big internet company, it is really easy to even implement a big stack of software with complicated architectures and many features -- but for a four people start-up it is a big problem.