• Content count

  • Joined

  • Last visited

About slaeshjag

  • Rank

  • Birthday 05/26/92

Contact Methods

  • MSN steven [at]
  • Website URL

Profile Information

  • Gender Male
  • Location ≈Stockholm, Sweden

Recent Profile Visitors

8027 profile views
  1. A possible PND-system replacement

    Well, they should have sensible name to begin with. There's no reason whatsoever to name a launch script other than maintainer lazyness/ignorance.   At most I can stretch to adding a config option that will add a suffix of the exec containing the package ID, but that really should not be needed.
  2. A possible PND-system replacement

    Ok, so the deal about launch scripts is:   They are placed by the dbp system in a directory as configured in /etc/dbp/sbp_config.ini They are not capable of overriding conf or anything like that. If a package wishes to export an executable that is already present in exec_dir, then dbpd will detect the collision, yell about it in /var/log_dbp_messages and refuse to export that exec for that package. If a collision occurs, the package that was identified the latest will probably end up launching the program/game of the package that was scanned first, or not launch at all. When packages are removed, the exported launchers are checked for a signature first to avoid removing anything that the DBP system didn't place there.   As things are configured right now during development, exported executables are placed in /usr/local/games, which has low priority in PATH and is not visible by root. For a more production environment, I personally suggest a new location dedicated to the DBP system that comes after core system utilities, and preferably after installed programs.   The reason for not having them local is for better integration with environments not using the traditional graphical style. A prime example is tiling WM:ers that use dmenu_run for launching stuff. This shortcoming of the PND system is one of few things that annoyed me enough to even get started working on dbp. Typing dbp-run <package id> <path to run script> in dmenu-run is an unacceptable solution.   On the matter of avoiding collisions, I suggest a helpful predictable name (say, name of the game) and if a collision is plausable (also available in debian repo, etc) then suffix with package name or something. There will be machanisms added later to specify packages that cause collisions, both dbp:s and deb:s.   EDIT: And, regarding screenshots: This could be solved at repo-level. Removing or adding screenshots to the package is not a terribly complicated thing to do on the repo, so getting it right at first is not critical. On package level, it'll only be implemented as a couple screenshots inside a directory in the meta-zip. If they're there, they're there.
  3. Download Pyra Debian OS (WIP)

    You placed it on your root filesystem, therefore it'll try to create its appdata directory on the root filesystem in /dragonbox, which normally isn't allowed.
  4. nVidia Jetson TX1 board

    Another consideration is that you got the SoC sitting right under the battery. With the OMAP5, the hope is to dissapate heat through the keyboard PCB. The Tegra board would have a big hunk of LiPo sitting right above it, which should preferably be kept as cool as possible. So a different way of getting the waste heat out would be needed.
  5. nVidia Jetson TX1 board

    Did you see the heatsink/fan on that thing? How well would it fit the thermal envelope of a Pyra-like device?
  6. Possible screen problem?

    Although the most common effect of an inductor on the run is the lack of backlight, isn't it?
  7. FunKeyMonkey

    The dbus system bus has a deny-all policy by default when it comes to owning names. Apart from changing the default, I am not aware of how to avoid the issue apart from adding rules.   This is a relatively recent change, probably happened in the last 5 years.
  8. FunKeyMonkey

    Lets just say that my first steps into dbus with dbpd was rough
  9. FunKeyMonkey

    Protip: If you go for a service on the system bus (which you should,) don't forget to create a rule in /etc/dbis-1/system.d, or you won't have permission to claim a name.
  10. Pyra Overlay

    Things are official when they get past the repo guard troll. It's something you'll have to persue yourself when it's ready.
  11. A possible PND-system replacement

    Then write your own damn repo. Don't complain about the tools of others if you're not doing the work yourself. I'm not writing the repo, so milkshake will have to comment on what he's prepared to use, but it'll probably involve PHP.   I require all dependencies that I'm to use to be present in the official repository of Debian Jessie, if they aren't, I'm not going to consider it.
  12. A date with the Pyra

    That image works about as well as anything else Ti has provided so far. It's barely a tech demo.
  13. A possible PND-system replacement

    Sundown isnt in repo. There is however another library for plain unextended markdown (libmarkdown2 in repo).
  14. A possible PND-system replacement

    Well, there need to be usable libraries for C and PHP, preferably in repo, for it to even be considrered..
  15. Pyra Overlay

    It isn't really a hassle if you plan for it from the start. Extending it with plugin support later however is a sure way to end up with lots of messy code duplication.