Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

I Can't Leave Well Enough Alone

stoolpigeon (454276) writes | about a year ago

User Journal 10

My desktop machine at work is now running Fedora 19. It just came out, I'm busy - what the heck is wrong with me?

My desktop machine at work is now running Fedora 19. It just came out, I'm busy - what the heck is wrong with me?

So something about how stuff works regarding the nvidia drivers, the kernel and what not changed. So that saga continues. Getting both my monitors working was a real exercise in pain. I tried a lot of stuff before I ended up with it working and I went down so many different trails that I don't remember for sure how I got here so I'm not even help to anyone else. Stand out moments were that lots of paths that included just plugging in the card and both monitors led to lock ups at various points in the booting up or getting KDE going process. So while I don't remember specifics I can say that in general- I did the main install using the on board video (intel) and a single monitor. When I got that all working (mostly) then I put in the Nvidia card and hooked it up to a single monitor. Then I installed the nvidia drivers. All was fine (mostly) and it was hooking up that second that made everything go square shaped.

What fixed it? I don't freaking know. The order of how things went? What was hooked up first and then second? I really don't know. I just know now that the nvidia drivers are working and it is using both screens and they look rather nice. That's all I know.

Oh but get this -- I posted a lot about my struggles with Firefox. Well right at this moment Chrome crashes X and kicks me back to logging in. Firefox works fine - and google hangouts works fine with Firefox. What?! I don't know. I can't explain it. It just is what it is. Starting Chrome makes SELinux complain - maybe that's related. Maybe the Google folks will fix it at some point. They update Chrome pretty regularly. I like Fedora better anyway. And Opera works fine. Konqueror too of course. Oh man - there were some early attempts where Konqueror was all that worked and those were fun times.

I've got the new kscreen deal for setting up screens. And it's so much better than the old stuff but frankly I'm terrified to go anywhere near it right now. I'm sort of scared of messing stuff up. The nvidia x server settings program runs and that seems sufficient. I had fun earlier when using either of them locked up the system and it wouldn't take input from the keyboard. That went away do to some amazing, smart thing I did without knowing it.

It's not all that crazy different from my F18 setup. Oh - I've got MariaDB now instead of MySQL and they don't have the MySQL workbench (data modeling is still borked) in the repos any more. I can't say I'm totally on board with this decision. Now I've got to keep track of it and update it when appropriate. And I get that Oracle is the evil - but whatever. If I'd been running the world back in the when it would be PostgreSQL everywhere and I wouldn't even have to worry about this.

Here's a fun error message that apparently doesn't really matter - "A start job is running for Wait for Plymouth Boot Screen to Quit." Have fun parsing that puppy.

cancel ×


Sorry! There are no comments related to the filter you selected.

MySQL workbench (1)

gd2shoe (747932) | about a year ago | (#44189107)

I haven't seen MySQL workbench in years, not since I had to use SQL (an evil, evil language). Even in its incomplete state, it was invaluable. I can't see how removing it is anything other than a brain-dead decision. Maybe they're planning to recreate it from scratch? (why?)

Re:MySQL workbench (1)

smitty_one_each (243267) | about a year ago | (#44189393)

Why do you H8 SQL? I actually kind of dig the stuff. Ah well, to each their own.

Re:MySQL workbench (1)

rk (6314) | about a year ago | (#44190855)

I like relational dbs, but SQL is kind of a crap language to access them. The default join is a Cartesian which is almost never what you want. The defaults for UPDATE and DELETE are to affect every row in the table. Yes, transactions prevent data loss here, but transactions aren't there to save us from crappy syntax.

Re:MySQL workbench (1)

smitty_one_each (243267) | about a year ago | (#44191061)

And your alternative is what, XML, and that wretched XQuery nonsense?
Sure, I use Cartesian joins, like, once a year, if I'm doing some find-unmatched report, and need to inject some records.
I guess the syntax could've been more regular or something, but I think they made INSERTs and UPDATEs look radically different for the casual reader, not the experienced pro generating the SQL on the fly.

Re:MySQL workbench (1)

rk (6314) | about a year ago | (#44197733)

Nope, all of those are horrible too. I have not actually put a lot of thought into what I would like a relational query language to look like. Now that I'm thinking about it, though, I'd like to give the problem some consideration.

Re:MySQL workbench (1)

smitty_one_each (243267) | about a year ago | (#44198953)

It seems that, as with regular expressions, the acme of skill is limiting the problem.

Re:MySQL workbench (1)

gd2shoe (747932) | about a year ago | (#44201085)

Regular expressions are cool, and extremely powerful. Now if only everyone could agree to ONE SYNTAX (sigh).

Back to SQL: not only is it a terrible language, but relational databases are all wrong for the typical use case. Don't get me wrong, RDBMs are infinitely valuable for the data storage/retrieval operations they were originally designed for, but they are just not designed for object persistence. They work (sometimes with great effort) to accomplish the task, but they simply aren't optimized for it.

Re:MySQL workbench (1)

smitty_one_each (243267) | about a year ago | (#44202245)

You make these assertions about "terrible language" -- what is it about the design goals of SQL you don't like?
"just not designed for object persistence" -- do you mean all of the overhead of normalizing data and casting it to canonical data types, as opposed to just dumping it to some key/value store a-la MongoDB?
I mean, sure, there is no universal tool that scales from a boot image to a data center. Yes, fanbois are tedious. But, other than PHP, I can find a little something to love in just about anything.

Re:MySQL workbench (1)

gd2shoe (747932) | about a year ago | (#44205583)

RDBMs are designed and optimized to handle data that naturally fit in tables. They're close kin to spreadsheets. There's a lot of data that behaves this way, and it's nice to have a solution tailored to them. A lot of data structures, though, especially dynamic ones, just don't fit well in a table. From the human perspective, it can be unreasonable to try to debug how a data structure is being stored. Ever try to store a B-tree in SQL? Even a doubly linked list can be trouble (especially when the data is not of a consistent type). Yes, they store. Yes, it can work, but getting data into and out of the system requires an undue number of potentially expensive operations, and a headache to normalize it (and another headache to detect and deal with "impedance mismatch"). Once the data is in, all the fancy operations that SQL is designed to do become meaningless. What are you going to do with a join on a leaf in a b-tree? The best you can do is retrieve it, and hand it back to the host program to deal with. If all you want is data persistence, there must be a better way. (Some languages offer better solutions, but I have yet to see a cross language solution that works. I presume they're out there somewhere.)

Key/value stores are worse, if anything.

As an aside, IT'S REALLY TEDIOUS TO TRY TO READ THINGS THAT ARE WRITTEN IN ALL CAPS. AFTER A WHILE, THEY MAKE MY EYES WATER. Yes, I know, SQL doesn't demand it, but it really is an annoying tradition.

As to the language itself, it's very rigid. Ever notice that? Every command has it's own syntax and it's own tokens. The syntax and API are inseparably intertwined. It was designed back before programmers decided that a minimum number of key words was a good idea. (According to MS, there are 174 keywords, and another 219 words that should be treated as keywords.) It lends itself to very long, complicated statements, mistakes are easier to make, and harder to debug than most languages. When adjusting tables themselves, typos have the potential to be disastrous. Error messages aren't real friendly (granted, better than compilers sometimes). Language bindings are typically clunky, or resort to requiring embedded SQL statements.

A few years ago, I'd have given a more thorough rant, but memories fade, even bad ones.

Back to the original topic, MySQL Workbench ameliorated some of these problems. I really can't understand having an SQL system without providing a tool designed to work around the flaws in the language.

Re:MySQL workbench (1)

smitty_one_each (243267) | about a year ago | (#44212111)

Concur strongly: data have their shapes. Some are tabular, some are tree-shaped, some are graph-like.
Two strategies for dealing with a syntax (perhaps naively) designed for easy non-nerd legibility:
a) Encase the sillier bits into strings, and interpolate (safe) data into the strings for execution,
b) Use an API against pre-compiled command objects, where the string interpolation/compilation is a performance bore.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>