GDB 7.6 Released(sourceware.org)
sourceware.org
GDB 7.6 Released
http://sourceware.org/ml/gdb-announce/2013/msg00000.html
3 comments
The mention of 'target record' reminds me that I should try to use the record/replay feature next time I debug something.
It is pretty neat, but I have yet to actually use it to fix a bug. The bugs that I cannot just spot tend to be bugs that occurred long ago in the program execution, something that record doesn't handle well (well, it could but it takes a lot of space to store all that info).
It seems that the only thing that reverse debugging helps me to do, i.e. find errors from not long ago, are something that is actually pretty easy to do. Maybe I am using it wrong.
It seems that the only thing that reverse debugging helps me to do, i.e. find errors from not long ago, are something that is actually pretty easy to do. Maybe I am using it wrong.
Just yesterday I used GDB for the first time in years because I fancied an alternative to Println debugging for Go. Works pretty well.
Isn't anybody shocked by the fact that the main release site is an FTP server?
> Release 7.6 of GDB, the GNU Debugger, is now available via anonymous FTP.
> ...
> You can download GDB from the GNU FTP server in the directory:
> Release 7.6 of GDB, the GNU Debugger, is now available via anonymous FTP.
> ...
> You can download GDB from the GNU FTP server in the directory:
ftp://ftp.gnu.org/gnu/gdbFTP is perfectly sufficient. Why should they use FTPS instead?
The cryto signature for the file is here ftp://ftp.gnu.org/gnu/gdb/gdb-7.6.tar.gz.sig
The cryto signature for the file is here ftp://ftp.gnu.org/gnu/gdb/gdb-7.6.tar.gz.sig
[deleted]
The releases are cryptographically signed, so its not an issue that the download is not done over SSL.
Or is there something else that worries you about FTP?
> Or is there something else that worries you about FTP?
You know what his objection likely is. Computing is a fashion industry now, so if you want to sound modern, you have to use something "new" solely because it is new, and stop using "old" stuff because it doesnt run on Rails and isnt agile or whatever.
You know what his objection likely is. Computing is a fashion industry now, so if you want to sound modern, you have to use something "new" solely because it is new, and stop using "old" stuff because it doesnt run on Rails and isnt agile or whatever.
As long as you use the term "The Cloud" to describe whatever it is, you're cool
Why would that be shocking? Seems pretty sensible.
GNU has been doing this for as long as I can remember. Why shocking?
Can http do downloads from an arbitrary offset to another ? Not a rhetorical question, genuinley curious.
A long long time ago I had written an application (out of a mix of curiosity, whim and as a learning excercise) to share rpm files (red hat package manager) peer to peer. I chose ftp because it could parallelize the download to max out my bandwidth.
Connectivity to the main servers used to be terrible in those days in India. Neither were there local mirrors with fat pipes.
A long long time ago I had written an application (out of a mix of curiosity, whim and as a learning excercise) to share rpm files (red hat package manager) peer to peer. I chose ftp because it could parallelize the download to max out my bandwidth.
Connectivity to the main servers used to be terrible in those days in India. Neither were there local mirrors with fat pipes.
> Can http do downloads from an arbitrary offset to
> another ? Not a rhetorical question, genuinley curious.
My natural inclination is to say "there's nothing wrong with this; if it ain't broke, don't fix it".
But I'm genuinely curious... why are you shocked by this? What is it about FTP that you consider inferior to other file distribution mechanisms?
But I'm genuinely curious... why are you shocked by this? What is it about FTP that you consider inferior to other file distribution mechanisms?
FTP is broken.
Practically speaking, its use of two ports often causes problems with residential ADSL that are often doubled-NATed (1st NAT at home router, 2nd NAT at the local gateway).
FTP is not secure. FTPS is but I haven't seen it used in ages.
FTP server programs are hard to write properly and properly secure. See the huge number of vulnerabilities in FTP programs.
The GNU project is already running an HTTP server. What does running an additional program with identical functionalities to a static HTTP server bring them? I see it as a not-so-useful expansion of the attack surface.
I am quite against blindingly following fashions in computing, but I fail to see what is the rationale for maintaining an FTP infrastructure for publishing files over simply serving them using plain HTTP.
Practically speaking, its use of two ports often causes problems with residential ADSL that are often doubled-NATed (1st NAT at home router, 2nd NAT at the local gateway).
FTP is not secure. FTPS is but I haven't seen it used in ages.
FTP server programs are hard to write properly and properly secure. See the huge number of vulnerabilities in FTP programs.
The GNU project is already running an HTTP server. What does running an additional program with identical functionalities to a static HTTP server bring them? I see it as a not-so-useful expansion of the attack surface.
I am quite against blindingly following fashions in computing, but I fail to see what is the rationale for maintaining an FTP infrastructure for publishing files over simply serving them using plain HTTP.
> Practically speaking, its use of two ports often causes problems with residential ADSL that are often doubled-NATed (1st NAT at home router, 2nd NAT at the local gateway).
Doesn't PASV mode solve this?
> FTP is not secure.
Neither is HTTP
> FTPS is but I haven't seen it used in ages.
Presumably because of the ubiquity of HTTPS, which is fair enough.
> The GNU project is already running an HTTP server. What does running an additional program with identical functionalities to a static HTTP server bring them? I see it as a not-so-useful expansion of the attack surface.
Presumably just tradition. I guess also that it's worked for the past 20+ years and they don't see a reason to change. I haven't checked but I imagine you could get the programs via HTTP as well.
> I am quite against blindingly following fashions in computing, but I fail to see what is the rationale for maintaining an FTP infrastructure for publishing files over simply serving them using plain HTTP.
As I see is, the main two advantages of FTP are that it's possible to browse the directory hierarchy, and to upload files. Of course both of these things can be done via HTTP, but in a non-standard manner (with the exception of WebDAV, though that is an extension to HTTP rather than part of HTTP itself).
I agree that FTP is less relevant today than it used to be, but I'm not sure that it's fundamentally broken. The two-way connection thing is the main problem as far as I'm concerned but as I understand it PASV mode solves that.
Doesn't PASV mode solve this?
> FTP is not secure.
Neither is HTTP
> FTPS is but I haven't seen it used in ages.
Presumably because of the ubiquity of HTTPS, which is fair enough.
> The GNU project is already running an HTTP server. What does running an additional program with identical functionalities to a static HTTP server bring them? I see it as a not-so-useful expansion of the attack surface.
Presumably just tradition. I guess also that it's worked for the past 20+ years and they don't see a reason to change. I haven't checked but I imagine you could get the programs via HTTP as well.
> I am quite against blindingly following fashions in computing, but I fail to see what is the rationale for maintaining an FTP infrastructure for publishing files over simply serving them using plain HTTP.
As I see is, the main two advantages of FTP are that it's possible to browse the directory hierarchy, and to upload files. Of course both of these things can be done via HTTP, but in a non-standard manner (with the exception of WebDAV, though that is an extension to HTTP rather than part of HTTP itself).
I agree that FTP is less relevant today than it used to be, but I'm not sure that it's fundamentally broken. The two-way connection thing is the main problem as far as I'm concerned but as I understand it PASV mode solves that.
It's not possible to upload files using FTP, if you care about preventing anonymous strangers from stealing your credentials and uploading their own files.
(And yet, many people still run FTP servers in public that allow uploads, and others upload to them over public/unencrypted WiFi. That's my personal gripe.)
(And yet, many people still run FTP servers in public that allow uploads, and others upload to them over public/unencrypted WiFi. That's my personal gripe.)
No?