Language:

en_US

switch to room list switch to menu My folders
Go to page: First ... 35 36 37 38 [39] 40 41 42 43 ... Last
[#] Tue May 07 2019 18:01:33 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Another cool trick I'm about to try involves recompiling glibc for the linux kernel you want to support, with the compiler you want to use.

This gets into an area of weird when you need to support a 10 year old kernel on the current compiler.

If this works, I would be able to cross-compile our product on a modern linux for old linuxes. Which means I can finally keep up-to-date on Jenkins, since the current Jenkins distributables require a java run time so modern, it doesn't work on 10 year old machines.

[#] Thu Jun 06 2019 16:08:54 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


CMake tantalizingly fails to work very well when you need to cross-compile.

I have a collection of files that I cannot know until after building all the executables. So, I need a post-build, pre-install/pre-packaging step that allows me to specify this collection of files so I can get them into the debian/RPM files.

CMake, though, isn't built to accomodate something like this... which, honestly, is kind of a basic requirement for a fair number of use cases. So, yeah.
Bravo, CMake. You fucking suck, yet you're the most popular system out there for this kind of thing.

*sigh*

[#] Fri Jun 14 2019 19:12:08 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


It's interesting, hiring a fresh programmer with little experience at the craft.

Not expecting the new hire to have much skill, I have to think more carefully about how I communicate about writing software. It's one of those things where you don't necessarily know what you know until you find someone who doesn't know what you know, and you have to think about how to discuss complex topics to a really intelligent person without being ridiculous and resorting to, say, baby-talk.

And then there's the random bits of technical details that come up. Today, I showed her the magic of 'arp -a' and how she can see the MAC addresses of all the machines she's talked to in her local network. That lead to an anecdote about hackers who poison arp tables to masquarade as other machines within the LAN, and how we needed to do this for an assessment we created to test students... which is one of those areas of our job that gets kind of fun, thinking of awful things you can do that you normally wouldn't want to do.

Not that *I* got to write such software... someone else had that opportunity.
But I maybe I'll write something like that for funzies at home.

[#] Fri Jun 21 2019 18:11:50 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


Anything's better than automake.

[#] Fri Jun 21 2019 18:50:35 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

GNU Autotools is Considered Harmful. I know this won't work for everyone, but the mainstream target systems do not differ as wildly as they did 20 years ago. I've started rolling my own (and playfully calling it "conf-IG-ure") and it seems to work better.

Cross compiling isn't on the table, though.

[#] Mon Jun 24 2019 14:37:48 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


I think CMake wants you to build tons of little packages that depend on each other. Which is, frankly, silly.

I have something that sorta-kinda seems to do the job after building this monster .cmake file, but the last quirk is to somehow modify any of these files I'm generating to create/set an environment variable to the base installation.

It looks like the way to do this is to call 'configure_file()', which causes the input file to be run through something that converts the variables therein to expanded values, generating a new file at the destination.

My concern, though, is that I have no idea when 'configure_file()' gets called.
If called during cpack (when building the debian or rpm package), great... this will work. But if called during the build, when I suspect it gets called, this isn't going to work for me, since I'm pre-generating the file(s) it intends to generate.

So... I'm eyeing this source code... and wondering...

[#] Thu Jun 27 2019 15:20:02 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Jenkins.

They encourage (read: force march) you to use this 'declarative' syntax for their Jenkinsfile. This syntax is an alternative to this 'Groovy' language, which itself is a derivative of Java.

Seriously. This is about as fucked up as you can possibly get while remaining semi-functional.

I've noticed a pattern. Whenever you need to do something that fundamentally requires a concept of programming, and you try to convert this concept of programming into something 'easier' so non-programmers can supposedly accomplish what a programmer accomplishes, you get something that fucks the world for everyone involved.

This declarative fucking format is another example in the steaming turdpile of other examples of this kind of bullshit.

Programming requires a certain mental quirk. A lot of people lack that quirk.
You should recognize when you can program it away, and when you can't, and be graceful.

[#] Thu Jun 27 2019 19:15:09 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


We've been getting along all right with it. I admit I'm not the guy primarily responsible for that mess, it's mostly somebody else problem ;)

We used to use non-Pipelines jenkins - ie just the Freeform module - at a previous job. Pipeliness seems to be all the rage now. You should be able to call shell scripts from it, if you need something more traditional.

[#] Thu Jun 27 2019 22:36:31 UTC from ParanoidDelusions

[Reply] [ReplyQuoted] [Headers] [Print]

 

Thu Jun 27 2019 11:20:02 EDT from fleeb @ Uncensored

Programming requires a certain mental quirk. A lot of people lack that quirk.
You should recognize when you can program it away, and when you can't, and be graceful.

Not just the quirk - there are other prerequisites too. 

I get the logic of programming - and if you throw me an Access database, I can create and customize a database using VBA modules that I can then troubleshoot and fine-tune and correct to make a database with a custom front end that does some pretty complex things like taking .csv files, parsing them and removing bad fields, sorting the good fields, importing them into a temporary table, then converting that table to a final table that is completely defined. 

But I've failed at C++, C#, and Java (and others) every time I've made a go at them - because I'm simply not good at math - I think. More than that - I just don't know how to do the math - and don't have the patience in me to learn how to do it at this late stage in the game. Complex arithmetic is beyond me. 

So I do a Java course - and I can get almost everything running the way I want - but the damn soccer balls go in the wrong direction when you click on the demo program every time, and eventually I give up. 

But I agree - there is a basic quirk that anyone interested in giving any kind of programming a try generally has. 

 



[#] Tue Jul 02 2019 11:17:04 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


LS:

Jenkins has done nearly everything possible to encourage the use of its pipelines stuff. I'm not necessarily against that, in that I strongly appreciate the notion of maintaining build scripts in source control (which pipelines encourage).
It's just their damned syntax is such horseshit.

The problem with calling a script is that you have to write one for Windows and one for Linux... it might be nice to just use one script that works on both environments.

The other problem is that you can't just call scripts to do everything that needs to be done. Wanna pull in dependencies from other build projects? You can't just use a shell script for that. You have to deal with their fucking not-so-Groovy language script language. There are some things I fundamentally cannot accomplish with Jenkins' non-Pipeline stuff (as in, permissions are absolutely fucking broken as all goddamn hell, as to render them completely useless... forcing you to use pipelines just so you can use their stoopid Credentials system, or suffer having to have all security exposed).

It isn't 'pipelines' that annoy me... it's this god-awful not-quite-a-language you're forced to use because some idiot wants to make the act of 'building' stuff friendly, and thinks this is the way to do it.

It isn't the way, though. It just makes folks who have enterprise development requirements have to deal with even more bullshit than normal.

PD:

I'm remarkably awful at basic arithmatic. I find it easier to explain that 2a + 2a = 4a than 2 + 2 = 4. And I think it's because the kind of math that I do best involves reducing observations to abstractions that I can manipulate, then pull back into reality again. It's the same thing that makes me appreciate music the way I do... I hear a melody, then sense it being played backwards later, and go, "Oh, there it is in retrograde... that's neat." Or I look at a trend in computing like 'convert something that requires programming at a fundamental level to a declarative language instead' and think, "Ford II was right."

[#] Thu Jul 04 2019 23:48:13 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

that needs to be done. Wanna pull in dependencies from other build
projects? You can't just use a shell script for that. You have to deal


Jenkins just isn't a dependency management system. It's an event triggered cron job with a fancy UI.

Since it's designed to support every programming language on the planet via plugins or shell scripts calling the native tools for that language, you generally have to manage dependencies via the native tools and artifact/repository system for the language.

There are exceptions, but they are exceptions. Even in the Java space, which is Jenkins' native tongue, the dependency management can't bs used in all cases.

[#] Tue Jul 09 2019 17:11:30 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Yeah, I get that Jenkins isn't a dependency management system. I'm not exactly trying to use it that way.

I am, however, wanting upstream projects to build when dependant projects build. That's kind of necessary for continuous integration. And I don't really have a problem with how it deals with dependencies... I prefer having to write all that stuff into the build scripts and such.

It's their godawful language that I find an abomination.

The world is populated with a lot of languages. A relative minority of people use Groovy. Why in fucks name would you not only use Groovy for your pipelines, but then bolt some weird-ass 'declarative' construct on top of it just to fuck with things some more?

[#] Tue Jul 09 2019 20:04:29 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


Because Jenkins is a java-based product and Groovy is basically the number one Java-hosted scripting language.

For better or for worse, using funny little dynamically-evaluated closures to define internal DSLs is common practice in the Groovy mentality. It's certainly got its upsides and downsides.

If you dislike this, never use Grails.

Actually, never use Grails, period.

[#] Fri Jul 12 2019 14:15:25 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Yeah, I don't have plans to use Grails.

And I would actual prefer to not use Java.

Maybe I should create a build system that doesn't require Java. Then, I could use JavaScript as a scripting language... something most developers know pretty well (even if it isn't exactly the spiffiest language out there).

Or, I'll just keep using Jenkins, since people throw money at me to do this other thing that I'm doing, and I need a build system that's free, yet provides continuous integration, and is at least reasonably well known.

[#] Wed Aug 14 2019 12:36:40 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Creating your own build system isn't as bad a thing as it used to be. The days of having a zillion different build targets that are all slightly different from each other are largely over. You don't have to detect whether you're running on HP/UX and use left-threaded system calls. Things are a lot simpler now.

[#] Mon Aug 26 2019 18:09:41 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Maybe.

Cross-compiling to work on 10-year old machines provides a bit more challenge that expected. Mostly in Linux.

You have to build your full stack of stuff to work on top of the oldest kernel you want to support.

Fortunately, I don't have to do the same with other unix clones, but I do need to do something like this with Windows. But it's easier in Windows, at least in some ways, because of the concern they had for maintaining backwards compatibility for so long.

[#] Mon Aug 26 2019 18:10:07 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Still, a full build system to work across the linux/windows divide would be nice, if one could do it without Java.

[#] Fri Aug 30 2019 15:26:10 UTC from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

Agreed, but the existence of things like containers seem to indicate that the world has given up on that goal.

[#] Tue Sep 03 2019 17:35:19 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Ford II isn't here to say, "Progress."

[#] Tue Sep 03 2019 21:31:32 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


How does one stay motivated to keep plugging away at a software development task when one has deep concerns about its inherent feasibility issues?

Like, nobody likes feeling like they've been set up to fail. And this thing could simply take longer than anybody really wants.

*meh.*

Go to page: First ... 35 36 37 38 [39] 40 41 42 43 ... Last