Ligatures are supported by the font and the font system system, so on computers whose font system is actually functional, ligatures also "just work" without any need for the browser to do anything special.
Interestingly, ligatures are broken in TFA. I checked with two different, modern browsers (Opera and w3m).
That's how you end up being PHP. Python 3 fixes core mistakes made in earlier versions of the language, and makes it harder to write bad code.
I now nothing about PHP, but almost *all* languages try to stay backwards-compatible, because their designers know how surprisingly hard it is in practice to migrate everyone.
Again, if you want a language where curlies are required, that's fine, but hopefully you can at least see that what Python does is both sensical and pragmatic.
Sorry, but pragmatic is not the right word.
The indentation-is-block-structure assumes people make sane editing choices, don't redefine the size of a TAB, and don't disagree about indentation level.
That's just not how the average programmer works, unfortunately.
I myself have lost a lot of time on this. When you're familiar with other languages, it's an odd feeling when you realize a small indentation fsckup forces you to start over from the beginning.
On the other hand, it's just one blemish on an otherwise good language, and not a reason to reject it.
It is rather pointless (and silly) for such a committee to waste time with such questions.
The point *is* being silly. Most people like a bit of silliness.
This group's yearly list of new words gets a lot of media attention in Sweden, and reminds people that the language is slowly being reshaped by what we do.
Your choice of distro depends a lot on you're needs or goals I suppose.
If you just want to learn linux for yourself and want to understand what is under the hood. Arch is...
And even *that* may mean different things.
I read man pages and edit configuration files, but don't circumwent the work which went into Debian -- is that "under the hood" or not?
Debian would also be a choice to look towards but I personnaly tend to not like how old the packages are... Debian testing would be better...
I don't mind the age of things in Debian stable much these days. Old Firefox/Iceweasel is a problem, when Facebook and other sites whine about it. Other than that, it's a problem if you really need to be bleeding-edge in some area, and most don't.
By the way, now is a good time to install Debian testing, since we're close to a release. Wait a few months, and your install will turn into the new, and recent, Debian stable.
The things I like about Debian are:
(a) There's no company wanting to make money from you. They are your friends.
(b) They like doing things the Unix way, e.g. value documentation and transparency.
IPv6 should be transparent to the application as well, yet still it remains largely unimplemented.
From my point of view (Linux), it is largely implemented at the endpoints by now. We just don't have many servers to talk to, and no ISPs willing to sell it to us.
Previously, if you wanted -g, you were recommended to use -O0, or you lose debugging fidelity
That's partially true and partially misleading.
No matter what optimization you use, -g provides stuff like instruction to file:line mapping, which is important in many scenarios (valgrind, gprof, pstack, analyzing core dumps...).
The debugging fidelity you speak of is mostly applicable when stepping around in a symbolic debugger, and many of us use those very rarely.
Personally I'll keep doing what I do now: compile using -g -Os from start to finish. If others are helped by -Og that's fine, as long as it doesn't hurt the features I'm interested in.
The hard part is writing the book of what NOT to do in C++.
How trite.
You don't need to do that: you write showing only good style.
Not with the readers being exposed to real-world C++ code, which tends to be based on either "I'm a C programmer and this is what I remember from a C++ course in 1997" or "I'd really like to pretend this is Java" at least as often as idiomatic C++.
Not that this is hard. I could probably throw together a brief chapter titled "A warning to C programmers" tonight.
I will never for the life of me understand the "uptime fetish" that uneducated sysadmins have. Who the hell cares? The only people who give a crap about this sort of thing are linux fanbois.
I don't care about uptime per se, but I hate to try to attach to a screen(1) session only to discover it's gone because someone decided it was somehow "good for the machine" to have a power cycle.
I don't ask for years of uptime, just no gratuitous reboots.
It's not bad. I have a P4 from 2005 w/ Windows XP sitting under my desk for legacy support. I use it to browse from time to time, it's fine for that.
Huh. The one I'm typing this on is an AMD64 from 2005. I use it for anything from programming to image editing to...
well, anything except running Windows. It's low-power and silent; around 2005 the manufacturers finally realized that people wanted those things. What possible reasons could I have to spend money (and scarce natural resources) on a new one?
Not just the radio. An older Nokia phone will easily last 2 weeks in standby mode too. It's the large, backlit, colour screen and the CPU / GPU that drain the battery life in a modern phone far faster than pinging a network tower periodically to let it know you're still active.
My Sony-Ericsson T610 lasts two weeks too, on its original 2003 battery -- and it *does* have a backlit (if smallish by today's standards) colour screen. I don't use it for IP traffic though.
I hope that the OP doesn't expect programmers to flock to support his project, just because it is present on a social coding site.
Indeed. It doesn't sound promising based on his posting. I get the impression that he expects to be able to sit back and manage ("coordinate skill set matching"?) flocking programmers. And there's this air of secretiveness -- what NPO are we talking about, and what are the projects? And there's the "emphasizes our non-profit as the benefactor" part which also is a major turn-off.
Who ever heard of volunteer programmers working on something they can't use themselves? There's no itch to scratch.
I think it would be silly to set-up your own server for this. GitHub is the goto place today. It has a good-enough Issues system that is well integrated with code management, and makes it easy to publish documentation.
To me, it's best feature is it stays out of your way.
It's not as bad as it used to be, but when I purchased redhat (back when one could go to the store and buy it), some random guy sneared and said "i wish people would use slackware, then you really have to know Linux"
Ok, but that's not necessarily elitism. Some of us genuinely believe that traditional Unix behavior (e.g. reading the documentation, understanding underlying concepts, editing text files,...) is the best way, for average users.
I've had pretty much the same experience, where anything that isn't Java or MySQL has landed me on SO or another site instead of the official documentation.
What weird stuff are you programming?
For me it's
C: man pages
Unix: man pages, and Stevens' book
C++: the SGI STL manual, or Stoustrup's book
Python: the Python documentation
Linux: read the kernel sources and guess
No way I would trust a random StackOverflow answer for anything close to important.
Nor would I trust a badly documented library -- if people can't explain what they've done, they probably didn't do a good job.
No thanks. As a software developer who has to deal with coders, they're literally more trouble than they're worth.
I didn't know there was such a distinction, and I'm horrified by the GP's idea that people cranking out code to specification without understanding *why* could produce anything useful. However...
To get good code out of them I have to nail things down so explicitly and in such detail that I could've written the code myself in the time it took to write the instructions for them. I nearly have to write the code anyway just to figure out all the stuff I need to give them instructions on. And if I don't give them instructions in that much detail, their lack of analytical ability means they churn out code that doesn't quite do what it's supposed to or does things in ways that conflict with what the rest of the system needs.
To be fair, it can start at the other end, too.
You can have a setup with Architects kidnapping the big picture, and treating the programmers as... well, "coders".
Like Stroustrup wrote, "An organisation that treats its programmers as morons will soon have
programmers that are willing and able to act like morons only."
And... there you have it. Every kindergarden class has toy xylophones and drums. Most of them don't have a Mozart. A few of them have future part-time musicians. The rest just make noise.
You know, that's why punk was invented.
Making your own music is more meaningful than listening to a recording of Brian May stroking his guitar (or whatever the options were in 1977).
But, I wonder how much it will actually increase the number of people that code. I think that inherently there are a small number of people that really have in inclination to enjoy coding.
I don't think that's true. People surprise you.
Many seem to enjoy games, puzzles, systems with strange and detailed rules, creating things... I don't see why they wouldn't be interested in programming, if they were given the chance.
I think the biggest change is that people in many fields will be using programming as a tool in their non-programming job. This is already the case, but it is largely informal. Computers as a job tool for everyone are going to move far beyond the office suite [...]
I certainly hope so, because people are in many ways treating computers as typewriters (and TVs). Lots of boring stuff is done manually or (worse) not done at all, because noone bothered to write a commercial utility to automate it. Or because it's a one-off thing.
This is where the traditional Unix approach shines.
The everyday interactive interface is also the programming interface. There's no false dichotomy between programmers and users.
Everyone from libraries and archives such as the Library of Congress (hi-resolution uncompressed TIFFs are the designated master file format for the National Digital Newspaper Program and the FADGI Still Image Working Group guidelines for digitizing cultural heritage materials)
Nice paper, but it feels a bit strange to read about PNG:
Possible format for production master file - not currently widely implemented.
It seems to me they recommend (not require) TIFF because TIFF is what they've always used, and their proprietary tools have good support for it.
Just because *you* don't use a file format anymore doesn't mean it's useless to others.
True, and as long as libtiff exists it's not a big problem.
I think you're leaving out some of the good stuff. The moon landings and the Large Hadron Collider make me feel a bit better about what humans are able to achieve.
IMHO Bob Marley and Shakespeare are two out of many better examples...
One option would be to take an existing FSF project which is currently abusing the filesystem as a database, and integrate optional database support into it, documenting and profiling performance as one proceeds. [...] go look for giant hairy directory trees in/var/lib/ and find out what project owns them.
Why is using the filesystem to store data somehow bad?
It's transparent, and if it's also text you can use version control tools to manage it. No such things are possible if it's a database somewhere.
It's very handy for generating both nroff man pages and their HTML counterparts from the same input text. Being extremely simple, it raises no barrier to writing man-page type documentation.
Neither does nroff -man.
If you're in a position where you'd want a man page, a percieved complexity in writing one in nroff is no excuse.
Read man(7), groff_man(7) and groff_char(7), and look at some example man pages for inspiration.
Also, if the cvs(1) man page of CVS 1.12.13 is a typical example of what Texinfo generates, I strongly recommend against using it for this. It's ugly and hard to read; doesn't really look like a man page at all.
People, who configured their ssh to listen to a non standard port, are aware of a problem and probably at least a bit more knowledgeable than the average user. So I'd expect better passwords and maybe other means of protection.
Either that, or they're more interested in tinkering with stuff, changing things that don't need changing... thus more likely to mess something up and leave a hole open.
Seems to me the problem is logs filled with crap, and the right solution is not to log failed PasswordAuthentication login attempts if you have disabled PasswordAuthentication. No idea if OpenSSH supports that.
I used the same technique back when people were doing the DNS cache poisoning attacks to limit how many hits my DNS could get from the same source (first query should update the cache in a legitimate site's DNS so no reason why I should get repeated hits from the same site).
Except if they're all behind NAT; then you're hurting legitimate users.
Slashdot Mirror
Ligatures are supported by the font and the font system system, so on computers whose font system is actually functional, ligatures also "just work" without any need for the browser to do anything special.
Interestingly, ligatures are broken in TFA. I checked with two different, modern browsers (Opera and w3m).
That's how you end up being PHP. Python 3 fixes core mistakes made in earlier versions of the language, and makes it harder to write bad code.
I now nothing about PHP, but almost *all* languages try to stay backwards-compatible, because their designers know how surprisingly hard it is in practice to migrate everyone.
Again, if you want a language where curlies are required, that's fine, but hopefully you can at least see that what Python does is both sensical and pragmatic.
Sorry, but pragmatic is not the right word. The indentation-is-block-structure assumes people make sane editing choices, don't redefine the size of a TAB, and don't disagree about indentation level. That's just not how the average programmer works, unfortunately. I myself have lost a lot of time on this. When you're familiar with other languages, it's an odd feeling when you realize a small indentation fsckup forces you to start over from the beginning.
On the other hand, it's just one blemish on an otherwise good language, and not a reason to reject it.
It is rather pointless (and silly) for such a committee to waste time with such questions.
The point *is* being silly. Most people like a bit of silliness. This group's yearly list of new words gets a lot of media attention in Sweden, and reminds people that the language is slowly being reshaped by what we do.
Your choice of distro depends a lot on you're needs or goals I suppose.
If you just want to learn linux for yourself and want to understand what is under the hood. Arch is ...
And even *that* may mean different things. I read man pages and edit configuration files, but don't circumwent the work which went into Debian -- is that "under the hood" or not?
Debian would also be a choice to look towards but I personnaly tend to not like how old the packages are ... Debian testing would be better ...
I don't mind the age of things in Debian stable much these days. Old Firefox/Iceweasel is a problem, when Facebook and other sites whine about it. Other than that, it's a problem if you really need to be bleeding-edge in some area, and most don't.
By the way, now is a good time to install Debian testing, since we're close to a release. Wait a few months, and your install will turn into the new, and recent, Debian stable.
The things I like about Debian are: (a) There's no company wanting to make money from you. They are your friends. (b) They like doing things the Unix way, e.g. value documentation and transparency.
IPv6 should be transparent to the application as well, yet still it remains largely unimplemented.
From my point of view (Linux), it is largely implemented at the endpoints by now. We just don't have many servers to talk to, and no ISPs willing to sell it to us.
Previously, if you wanted -g, you were recommended to use -O0, or you lose debugging fidelity
That's partially true and partially misleading. No matter what optimization you use, -g provides stuff like instruction to file:line mapping, which is important in many scenarios (valgrind, gprof, pstack, analyzing core dumps ...).
The debugging fidelity you speak of is mostly applicable when stepping around in a symbolic debugger, and many of us use those very rarely.
Personally I'll keep doing what I do now: compile using -g -Os from start to finish. If others are helped by -Og that's fine, as long as it doesn't hurt the features I'm interested in.
The hard part is writing the book of what NOT to do in C++.
How trite. You don't need to do that: you write showing only good style.
Not with the readers being exposed to real-world C++ code, which tends to be based on either "I'm a C programmer and this is what I remember from a C++ course in 1997" or "I'd really like to pretend this is Java" at least as often as idiomatic C++.
Not that this is hard. I could probably throw together a brief chapter titled "A warning to C programmers" tonight.
I will never for the life of me understand the "uptime fetish" that uneducated sysadmins have. Who the hell cares? The only people who give a crap about this sort of thing are linux fanbois.
I don't care about uptime per se, but I hate to try to attach to a screen(1) session only to discover it's gone because someone decided it was somehow "good for the machine" to have a power cycle.
I don't ask for years of uptime, just no gratuitous reboots.
It's not bad. I have a P4 from 2005 w/ Windows XP sitting under my desk for legacy support. I use it to browse from time to time, it's fine for that.
Huh. The one I'm typing this on is an AMD64 from 2005. I use it for anything from programming to image editing to ...
well, anything except running Windows. It's low-power and silent; around 2005 the manufacturers finally realized that people wanted those things. What possible reasons could I have to spend money (and scarce natural resources) on a new one?
Not just the radio. An older Nokia phone will easily last 2 weeks in standby mode too. It's the large, backlit, colour screen and the CPU / GPU that drain the battery life in a modern phone far faster than pinging a network tower periodically to let it know you're still active.
My Sony-Ericsson T610 lasts two weeks too, on its original 2003 battery -- and it *does* have a backlit (if smallish by today's standards) colour screen. I don't use it for IP traffic though.
I hope that the OP doesn't expect programmers to flock to support his project, just because it is present on a social coding site.
Indeed. It doesn't sound promising based on his posting. I get the impression that he expects to be able to sit back and manage ("coordinate skill set matching"?) flocking programmers. And there's this air of secretiveness -- what NPO are we talking about, and what are the projects? And there's the "emphasizes our non-profit as the benefactor" part which also is a major turn-off. Who ever heard of volunteer programmers working on something they can't use themselves? There's no itch to scratch.
I think it would be silly to set-up your own server for this. GitHub is the goto place today. It has a good-enough Issues system that is well integrated with code management, and makes it easy to publish documentation.
To me, it's best feature is it stays out of your way.
It's not as bad as it used to be, but when I purchased redhat (back when one could go to the store and buy it), some random guy sneared and said "i wish people would use slackware, then you really have to know Linux"
Ok, but that's not necessarily elitism. Some of us genuinely believe that traditional Unix behavior (e.g. reading the documentation, understanding underlying concepts, editing text files, ...) is the best way, for average users.
I've had pretty much the same experience, where anything that isn't Java or MySQL has landed me on SO or another site instead of the official documentation.
What weird stuff are you programming? For me it's
No way I would trust a random StackOverflow answer for anything close to important. Nor would I trust a badly documented library -- if people can't explain what they've done, they probably didn't do a good job.
No thanks. As a software developer who has to deal with coders, they're literally more trouble than they're worth.
I didn't know there was such a distinction, and I'm horrified by the GP's idea that people cranking out code to specification without understanding *why* could produce anything useful. However ...
To get good code out of them I have to nail things down so explicitly and in such detail that I could've written the code myself in the time it took to write the instructions for them. I nearly have to write the code anyway just to figure out all the stuff I need to give them instructions on. And if I don't give them instructions in that much detail, their lack of analytical ability means they churn out code that doesn't quite do what it's supposed to or does things in ways that conflict with what the rest of the system needs.
To be fair, it can start at the other end, too. You can have a setup with Architects kidnapping the big picture, and treating the programmers as ... well, "coders".
Like Stroustrup wrote, "An organisation that treats its programmers as morons will soon have
programmers that are willing and able to act like morons only."
Ask me about something real!
That would, by the way, look really good on a t-shirt.
And... there you have it. Every kindergarden class has toy xylophones and drums. Most of them don't have a Mozart. A few of them have future part-time musicians. The rest just make noise.
You know, that's why punk was invented. Making your own music is more meaningful than listening to a recording of Brian May stroking his guitar (or whatever the options were in 1977).
But, I wonder how much it will actually increase the number of people that code. I think that inherently there are a small number of people that really have in inclination to enjoy coding.
I don't think that's true. People surprise you. Many seem to enjoy games, puzzles, systems with strange and detailed rules, creating things ... I don't see why they wouldn't be interested in programming, if they were given the chance.
I think the biggest change is that people in many fields will be using programming as a tool in their non-programming job. This is already the case, but it is largely informal. Computers as a job tool for everyone are going to move far beyond the office suite [...]
I certainly hope so, because people are in many ways treating computers as typewriters (and TVs). Lots of boring stuff is done manually or (worse) not done at all, because noone bothered to write a commercial utility to automate it. Or because it's a one-off thing.
This is where the traditional Unix approach shines. The everyday interactive interface is also the programming interface. There's no false dichotomy between programmers and users.
Who on earth uses Tiff anymore?
Everyone from libraries and archives such as the Library of Congress (hi-resolution uncompressed TIFFs are the designated master file format for the National Digital Newspaper Program and the FADGI Still Image Working Group guidelines for digitizing cultural heritage materials)
Nice paper, but it feels a bit strange to read about PNG:
It seems to me they recommend (not require) TIFF because TIFF is what they've always used, and their proprietary tools have good support for it.
Just because *you* don't use a file format anymore doesn't mean it's useless to others.
True, and as long as libtiff exists it's not a big problem.
I think you're leaving out some of the good stuff. The moon landings and the Large Hadron Collider make me feel a bit better about what humans are able to achieve.
IMHO Bob Marley and Shakespeare are two out of many better examples ...
One option would be to take an existing FSF project which is currently abusing the filesystem as a database, and integrate optional database support into it, documenting and profiling performance as one proceeds. [...] go look for giant hairy directory trees in /var/lib/ and find out what project owns them.
Why is using the filesystem to store data somehow bad? It's transparent, and if it's also text you can use version control tools to manage it. No such things are possible if it's a database somewhere.
It's very handy for generating both nroff man pages and their HTML counterparts from the same input text. Being extremely simple, it raises no barrier to writing man-page type documentation.
Neither does nroff -man. If you're in a position where you'd want a man page, a percieved complexity in writing one in nroff is no excuse. Read man(7), groff_man(7) and groff_char(7), and look at some example man pages for inspiration.
Also, if the cvs(1) man page of CVS 1.12.13 is a typical example of what Texinfo generates, I strongly recommend against using it for this. It's ugly and hard to read; doesn't really look like a man page at all.
People, who configured their ssh to listen to a non standard port, are aware of a problem and probably at least a bit more knowledgeable than the average user. So I'd expect better passwords and maybe other means of protection.
Either that, or they're more interested in tinkering with stuff, changing things that don't need changing ... thus more likely to mess something up and leave a hole open.
Seems to me the problem is logs filled with crap, and the right solution is not to log failed PasswordAuthentication login attempts if you have disabled PasswordAuthentication. No idea if OpenSSH supports that.
I used the same technique back when people were doing the DNS cache poisoning attacks to limit how many hits my DNS could get from the same source (first query should update the cache in a legitimate site's DNS so no reason why I should get repeated hits from the same site).
Except if they're all behind NAT; then you're hurting legitimate users.