Extra features and configurability aren't always a good thing at all. The KDE control center is atrocious with far too many panels, tabs, dialogs arranged illogically with common settings mixed in amongst obscure settings.
I wholeheartedly agreee... I've always been turned off by the sheer number of configurations that are presented in the GUI. Something more along the lines of Firefox/Thunderbird may be more appropriate, where there's a GUI to handle the common cases, and some sort of "raw configuration" access for the rare cases (like tuning your TCP/IP stack).
But here's the real kicker. KDE's configuration is all stored in nice little files in your home directory (IIRC, it's ~/.kde/config/*). The config files are all easy to edit by hand, assuming you have any sort of external documentation (say... maybe something on kde.org? Not sure, haven't looked it up recently). For anyone trying to synchronize desktop settings between machines, having an/etc-like tree of INI-style configuration files sure beats Gnome's registry solution. I like to put my configuration files in subversion (and be able to see *meaningful* diffs), so KDE works great for me. Configure once, run everywhere.
Re:do not stop progress by not wanting 'bloat'...
on
KDE 4.0 RC 1 Released
·
· Score: 2, Interesting
But the whole "discussion" between gnome and kde is so useless. And also the bloated thing. Who cares? More and more people (will) have multiple cores and a few Giga bytes of memory. If the window manager uses some of these resources and it makes your job easier, please do!!! In case you have a smaller computer, then go and use a smaller desktop system.
I ran into this issue at work, where my computer was an 800MHz Celeron, I believe. I was originally running Gnome, but switched to fluxbox + aterm and it made a world of a difference in terms of overall desktop responsiveness. There are plenty of people who aren't running multicore boxes and don't have a few GB of memory lying around. If KDE/Gnome can be developed to run on low-end machines and still feel "good enough", then they should be blazingly fast on the ungodly-overpowered desktop machines that are the high end of today's desktop market.
The biggest issue, IMO, is that running Konsole outside of KDE costs nearly as much system resources as running KDE all-out. If that extends to other KDE-based applications, that basically rules any KDE app from being used on a machine like I described without performance penalties. The machine shouldn't have to be powerful enough just to run a desktop environment. That's the same path that Vista is going down, where you need a supercomputer just to log in.
In fairness to the KDE folks, despite my complaints about the bloat, it still takes up less memory than Firefox (I was a web developer... working in Opera... because 800MHz isn't always enough for Firefox).
utilize the power of deterministic destruction, that C# and Java lack, to arrange it so that resources, including but not limited to just memory, are auto-freed.
That is incorrect. Java has had WeakReference since 1.2 release which was in 1998.
Weak References have nothing to do with RAII. RAII is more along the lines of "replace all of the code in finally clauses with encapsulated cleanup by the objects themselves". By converting dynamic (and thus scopeless) resource allocation into stack-based scoped allocation, your cleanup is guaranteed to run when you decide. Java finalizers are similar, but are nondeterministic and may never execute if the JVM decides it so, making them useless for cleanup tasks.
On the contrary, I don't think I've never really been in touch with the state of technology (in this particular arena) to begin with. I'm not an admin. My point of view is coming from the fact that to log in remotely at my present job, I need the little keyfob, plus a PIN to go with it, plus my Windows domain login... then my windows domain login again, because apparently the first time through wasn't enough to convince the system that I am me. There are many possible levels of security to select, and the more secure ones do come with increased cost. Not all companies are big, and if it's cheaper to just use SSH (or a VPN) and enforce strong passwords, then that may be more appropriate than fully-fledged two-factor authentication.
If your application follows the n-tier or MVC architectures, there's no reason for your database server to be exposed in the first place. No database should ever be accessible directly from the Internet..ever. If you feel differently, then you probably need to reevaluate your design strategy.
I feel differently. Why should I write an application server on top of my database, when all of my real processing fits perfectly well (and is completely expressible) via a combination of views and stored procedures? If I give someone a database schema and a set of stored procedures they're allowed to call, I've simplified the API. I can switch my internals from Python to Ruby to Perl to C and none of it matters, because I'm using the database as the API.
The architectures that all involve using a database as a dumb storage device all assume that the database vendor can switch at any moment. I take it the other way... the database isn't going anywhere, but the languages used to work with it are easy to change. Of course, this involves using something at least as powerful as Postgres, and preferrably more (since PG is, afaik, still working on the permission system with functions).
You should be requiring two-factor authentiction [sic], either with smartcards or with one-time-passhprase fobs for ANY remote connections in to your internal network.
Bah! I say if you want to send a remote connection, the only secure way to do it is TCP over snail mail through a trusted human relay (who will the netcat the data from his local desktop to the appropriate server, or bounce the mail). It's even better if you can convince the trusted human relay to just bounce everything.
Another small thing you can do is to change the port that MySQL is listening on, but haven't bothered to go that far yet - the existing security seems to have been pretty solid.
That will stop any access due to network scanning (e.g. search the block 10.0.0.0/24 for anyone with an open port 3306), but it won't do jack shit about anyone who is actually interested in finding out if you have MySQL running. The tool nmap is particularly good at identifying protocols, and I'm sure it has MySQL figured out. Moving your server to a different port will not effect any additional security; it will just eliminate some of the noise.
# iptables -I INPUT 1 -dport 3306 -j DROP -- how hard can that be?
I don't think that's such a good idea... pointing people towards iptables is a good way to get half-ass firewalls that sorta work, but not really. Most people just aren't going to get the right firewall configuration (and I don't blame them). Better to advertise something higher-level than what essentially amounts to kernel interfaces!
Did you ever consider that it's exactly this kind of laziness which microsoft is counting on, when it uses generic names like "SQL Server" and "Windows" and "Word" for it's products?
Having talked about databases with co-workers and friends enough, I would say that anyone even semi-professional understands by context that "SQL Server" refers to MSSQL specifically (actually, I've heard some people just refer to it as Sybase, but that's another issue). The only place I've had any ambiguouity was with one friend who was a new Windows admin, and didn't really understand the concept of SQL itself yet. So i guess... yes, you are correct; the generic names add some confusion. But it's nothing to get your panties in a bunch about, because it naturally weeds itself out as skill level increases.
Anyways, I'm a fan of straightforward names. I'd rather they call it "SQL Server" than something gimmicky like "RaptorServ". One of those is an accurate description of the role the product fills; another is... acceptable as a codename for a product, but certainly not for an end product. I've seen blogs where Visual Studio developers refer to Orcas, and before I knew that Orcas meant "Visual Studio 2008 development", I was completely lost.
So if printf() goes tits-up, it's highly unlikely that any attempt to display an error message will work either.
But if you have syslog, maybe that works... or maybe the logfile you have open works... or maybe you can open up an SMTP connection and send an email out. There's all sorts of reasons why some channel may fail and others are still available, and should be used to indicate a systemic failure.
(I suppose you could exit non-zero, but who checks exit codes in shell scripts?)
Hey! I do! If you write shell scripts and you don't care about return codes... maybe you shouldn't be programming. Let someone else do it right, so it doesn't start failing mysteriously in 3 years when some obscure part of the operating system changes and breaks your script.
So, it's an error when printf() doesn't output the expected number of bytes. Check.
If you read the documentation for those functions (man 3 printf), you'll see that an error is signalled by returning a negative value. The length is not to be used for error-analysis unless it's negative. It's more for something like this:
In those cases, its a good idea to not check for any exception you can't correct or at least add some useful information to on the way out. You do need, however, to detect error conditions resulting from the way your code is used that aren't thrown as exceptions by lower-level code and throw them as exceptions yourself...
Ahhh... reminds me of my take on an ideal C++ environment:
Write everything to be as strongly exception-safe as possible (no memory leaks, provide transactional semantics where reasonable or expected)
Don't ever think about catching an exception unless you can promise to do something more useful than your caller will.
One try/catch block inside main() is enough to spit out the failure and shut down gracefullyWhich raises a question: does anyone know if there is a way to make gdb automatically add breakpoints to all exception throw calls?
...isnt this the rationale behind SOAP and such? Why leave a DB port open on the Internet.
Why leave a SOAP port open on the Internet? What if I trust my DB vendor more than I trust the SOAP middleware? SOAP doesn't "protect" you from anything, it just moves the administration out frying pan (IP-based access control such as iptables, VPNs, and hardware by Cisco et al) and into the fire of a SOAP vendor—who, by the way, more or less implements the same sort of access controls as were previously available. Only now, there's more of a learning curve because the toolsets aren't as well-known.
Those I understand, but what's with Americans spelling ensure with an "i"? As in "I will insure that I spell correctly". To me that's just bizzare, who is going to pay out damages on your poor spelling?
As an American, I want to say that it's not an American thing—it's an ignorance thing. Same with looser/loser and affect/effect.
I can't claim anything about the correlation between Americans and misspellers, though... so maybe you're still right.
Just put that there is a $100 fee for using a phone in the theatre as a condition on the tickets and rake in the extra cash. Another solution is to take photos of people and put them on a big board titled "People who have been banned for cell phone use"
I'd like to see you try that and stay in business.
My box of records weighs 80lbs and contains only a few dozen CDs. When the fires threatened my house I left it.
My 400 disc cases of CDs (all 4 of them) combined were light enough that my 9 year old carried them to the car when the fires were coming.
It sounds like you have more serious problems in life, man.
A digital, thus time-discrete and value-discrete recording can only ever approximate the original.
Since sound is based on compressions and rarefactions in a medium, and at any given point in time we can discretize media into individual particles, I'd say that the original recording is time-discrete and value-discrete. After all, any digital medium looks analog from far enough away; we just have to advance to the point where no one can tell the difference.
The truth of the matter is that vinyl records are crap compared to CD's in every measurable way - distortion, dynamic range, frequency response, signal to noise ratio, you name it.
A similar statement can be made about the superiority of a digital photograph to the medium of oil paint and canvas.
Oil paint and canvas are for painting, not photography. Both are fairly entrenched art forms, and neither one is going to replace the other because they do different things. You may be better off comparing digital photography with film photography. Much in the same way that transistors distort differently than tubes (transistors are more linear and clip hard when they peak), digital film distorts differently than analog (particularly highlights). In many cases, film still has superior dynamic range and and resolution.
Analog audio distorts more smoothly (no hard clips), and handles time-compression/expansion and pitch shifting much better than digital. But in the end, the cost of high-quality analog devices far outweighs the cost of high-quality digital devices, and the benefits for using analog are slim to none for a listener.
Woah... car modders of the serious sort do care about speed. Everything they do, the good ones, is about shedding weight and adding horsepower and torque and stopping power
Have a party, and try putting 50 CDs in your multidisc CD player - Put 20 CDs from 1994 and 20 CDs from 2000 and 10 CDs from 2007. Now hit random.
That's a good argument for putting compression hardware onto the playback device... which is generally a good idea anyways (though most units call it "night mode"). The problem is that the recordings coming out already have clipping due to 0dB sustained peaks. You can reverse linear compression (lossily) at the playback side... but you can't reverse clipping.
Music as a "party background" is possibly the lowest common denominator, and isn't really a justification for deliberately destroying the engineering on 99% of the music.
I am not quite sure what the implication is here. "Table" is only a conceptual presentation view. You can store 3D coordinates, or 11D coordinates if you want. How you display them in actual space depends on the display device and transformation views you use.
You're still looking at it from a two-dimensional point of view. Not the data you store, but your data-storage mechanism. There are two axes in a table:
The set of available columns in a table
The set of available rows in a table
What if you took one (or both) of those axes away? What if you added more axes? Relational tuple calculus (tables) is generally only 2D. You could consider enumerated values as a third dimension (in the same way that enumerated columns are a second dimension).
From an algebraic point of view, that's scalar (0D)-> vector (1D) -> matrix (2D) -> tensor (3D) -> ??? -> profit.
From a mesh-topological view (e.g. 3D geometry), that's point (0D) -> line (1D) -> surface (2D) -> volume (3D) -> ??? -> profit.
Actually, that is what QOS is for. Segmenting off everyone that wants to do some transfer makes for a fragmented unsummarized network with stretch VLANS all over god and country. Segmenting in little networks is fine...but a disaster in large ones.
You're missing where one of the parents commented about cases where speed matters. If you're doing algorithmic trading and you're using software QoS, and your competitor is using physical hardware segmentation, your competitor wins (all other things being equal).
Slashdot Mirror
I wholeheartedly agreee... I've always been turned off by the sheer number of configurations that are presented in the GUI. Something more along the lines of Firefox/Thunderbird may be more appropriate, where there's a GUI to handle the common cases, and some sort of "raw configuration" access for the rare cases (like tuning your TCP/IP stack).
But here's the real kicker. KDE's configuration is all stored in nice little files in your home directory (IIRC, it's ~/.kde/config/*). The config files are all easy to edit by hand, assuming you have any sort of external documentation (say... maybe something on kde.org? Not sure, haven't looked it up recently). For anyone trying to synchronize desktop settings between machines, having an /etc-like tree of INI-style configuration files sure beats Gnome's registry solution. I like to put my configuration files in subversion (and be able to see *meaningful* diffs), so KDE works great for me. Configure once, run everywhere.
I ran into this issue at work, where my computer was an 800MHz Celeron, I believe. I was originally running Gnome, but switched to fluxbox + aterm and it made a world of a difference in terms of overall desktop responsiveness. There are plenty of people who aren't running multicore boxes and don't have a few GB of memory lying around. If KDE/Gnome can be developed to run on low-end machines and still feel "good enough", then they should be blazingly fast on the ungodly-overpowered desktop machines that are the high end of today's desktop market.
The biggest issue, IMO, is that running Konsole outside of KDE costs nearly as much system resources as running KDE all-out. If that extends to other KDE-based applications, that basically rules any KDE app from being used on a machine like I described without performance penalties. The machine shouldn't have to be powerful enough just to run a desktop environment. That's the same path that Vista is going down, where you need a supercomputer just to log in.
In fairness to the KDE folks, despite my complaints about the bloat, it still takes up less memory than Firefox (I was a web developer... working in Opera... because 800MHz isn't always enough for Firefox).
I feel differently. Why should I write an application server on top of my database, when all of my real processing fits perfectly well (and is completely expressible) via a combination of views and stored procedures? If I give someone a database schema and a set of stored procedures they're allowed to call, I've simplified the API. I can switch my internals from Python to Ruby to Perl to C and none of it matters, because I'm using the database as the API.
The architectures that all involve using a database as a dumb storage device all assume that the database vendor can switch at any moment. I take it the other way... the database isn't going anywhere, but the languages used to work with it are easy to change. Of course, this involves using something at least as powerful as Postgres, and preferrably more (since PG is, afaik, still working on the permission system with functions).
Bah! I say if you want to send a remote connection, the only secure way to do it is TCP over snail mail through a trusted human relay (who will the netcat the data from his local desktop to the appropriate server, or bounce the mail). It's even better if you can convince the trusted human relay to just bounce everything.
That will stop any access due to network scanning (e.g. search the block 10.0.0.0/24 for anyone with an open port 3306), but it won't do jack shit about anyone who is actually interested in finding out if you have MySQL running. The tool nmap is particularly good at identifying protocols, and I'm sure it has MySQL figured out. Moving your server to a different port will not effect any additional security; it will just eliminate some of the noise.
I don't think that's such a good idea... pointing people towards iptables is a good way to get half-ass firewalls that sorta work, but not really. Most people just aren't going to get the right firewall configuration (and I don't blame them). Better to advertise something higher-level than what essentially amounts to kernel interfaces!
Having talked about databases with co-workers and friends enough, I would say that anyone even semi-professional understands by context that "SQL Server" refers to MSSQL specifically (actually, I've heard some people just refer to it as Sybase, but that's another issue). The only place I've had any ambiguouity was with one friend who was a new Windows admin, and didn't really understand the concept of SQL itself yet. So i guess... yes, you are correct; the generic names add some confusion. But it's nothing to get your panties in a bunch about, because it naturally weeds itself out as skill level increases.
Anyways, I'm a fan of straightforward names. I'd rather they call it "SQL Server" than something gimmicky like "RaptorServ". One of those is an accurate description of the role the product fills; another is... acceptable as a codename for a product, but certainly not for an end product. I've seen blogs where Visual Studio developers refer to Orcas, and before I knew that Orcas meant "Visual Studio 2008 development", I was completely lost.
But if you have syslog, maybe that works... or maybe the logfile you have open works... or maybe you can open up an SMTP connection and send an email out. There's all sorts of reasons why some channel may fail and others are still available, and should be used to indicate a systemic failure.
Hey! I do! If you write shell scripts and you don't care about return codes... maybe you shouldn't be programming. Let someone else do it right, so it doesn't start failing mysteriously in 3 years when some obscure part of the operating system changes and breaks your script.
If you read the documentation for those functions (man 3 printf), you'll see that an error is signalled by returning a negative value. The length is not to be used for error-analysis unless it's negative. It's more for something like this:
- Write everything to be as strongly exception-safe as possible (no memory leaks, provide transactional semantics where reasonable or expected)
- Throw exceptions whenever something truly exceptional happens.
- Don't ever think about catching an exception unless you can promise to do something more useful than your caller will.
One try/catch block inside main() is enough to spit out the failure and shut down gracefullyWhich raises a question: does anyone know if there is a way to make gdb automatically add breakpoints to all exception throw calls?You misspelled critism, good sir. Candians deserve the crisim.
As an American, I want to say that it's not an American thing—it's an ignorance thing. Same with looser/loser and affect/effect.
I can't claim anything about the correlation between Americans and misspellers, though... so maybe you're still right.
I'd like to see you try that and stay in business.
It sounds like you have more serious problems in life, man.
Since sound is based on compressions and rarefactions in a medium, and at any given point in time we can discretize media into individual particles, I'd say that the original recording is time-discrete and value-discrete. After all, any digital medium looks analog from far enough away; we just have to advance to the point where no one can tell the difference.
Oil paint and canvas are for painting, not photography. Both are fairly entrenched art forms, and neither one is going to replace the other because they do different things. You may be better off comparing digital photography with film photography. Much in the same way that transistors distort differently than tubes (transistors are more linear and clip hard when they peak), digital film distorts differently than analog (particularly highlights). In many cases, film still has superior dynamic range and and resolution.
Analog audio distorts more smoothly (no hard clips), and handles time-compression/expansion and pitch shifting much better than digital. But in the end, the cost of high-quality analog devices far outweighs the cost of high-quality digital devices, and the benefits for using analog are slim to none for a listener.
I hope they poop before they race!
That's a good argument for putting compression hardware onto the playback device... which is generally a good idea anyways (though most units call it "night mode"). The problem is that the recordings coming out already have clipping due to 0dB sustained peaks. You can reverse linear compression (lossily) at the playback side... but you can't reverse clipping.
Music as a "party background" is possibly the lowest common denominator, and isn't really a justification for deliberately destroying the engineering on 99% of the music.
I believe the World Wide Web and a href beg to differ. Links simply exist to join document fragments together non-hierarchically.
You're still looking at it from a two-dimensional point of view. Not the data you store, but your data-storage mechanism. There are two axes in a table:
What if you took one (or both) of those axes away? What if you added more axes? Relational tuple calculus (tables) is generally only 2D. You could consider enumerated values as a third dimension (in the same way that enumerated columns are a second dimension).
From an algebraic point of view, that's scalar (0D)-> vector (1D) -> matrix (2D) -> tensor (3D) -> ??? -> profit.
From a mesh-topological view (e.g. 3D geometry), that's point (0D) -> line (1D) -> surface (2D) -> volume (3D) -> ??? -> profit.
You're missing where one of the parents commented about cases where speed matters. If you're doing algorithmic trading and you're using software QoS, and your competitor is using physical hardware segmentation, your competitor wins (all other things being equal).
$stmt = $dbh->prepare('STEAL $1 FROM banks WHERE bank_name = $2');
$stmt->execute(100.00, 'Wells Fargo');