Vis innlegg

Denne delen lar deg se alle innlegg laget av dette medlemmet. Merk at du bare kan se innlegg gjort i områder du har tilgang til.


Meldinger - Floyd-ATC

Sider: 1 [2] 3 4 ... 52
16
Minecraft / Sv: Schematic eksport forespørsel
« på: 18. Januar 2017, 17:25 pm »
Oppdatering: Logg inn på websiden som Cybersyn nå, så tror jeg du skal finne begge deler :-)

17
Minecraft / Sv: Schematic eksport forespørsel
« på: 18. Januar 2017, 17:15 pm »
Hei

Jeg skal forsøke å få det til men akkurat nå kommer jeg ikke inn fordi den smartingen Thor Arne har "lånt" minecraft-brukeren min og byttet både ingame-navn og passord på den. Passordet var null problem å tilbakestille men ingame-navnet "FloydATC" er da visstnok opptatt og dermed er jeg i praksis ikke lenger OP på egen server. Hipp hurra.

18
Generelt teknisk / CentOS 7 nmap-ncat does not support SOCKS5
« på: 16. Oktober 2016, 19:59 pm »
Tunneling an ssh session through a SOCKS5 proxy (e.g. using Tor) should be possible by adding the following to your
Kode: [Velg]
/etc/ssh/ssh_config file:

Kode: [Velg]
Host *.example.com
        CheckHostIP no
        Compression yes
        Protocol 2
        ProxyCommand ncat --nodns --proxy-type socks5 --proxy 127.0.0.1:9050 %h %p

Unfortunately, RHEL7/CentOS 7 ships with a rather antiquated version of nmap-ncat (a modern replacement for the now unmaintained BSD netcat) and this version only supports socks4.

Trying to use socks4 is similar to using no proxy at all, it fails with the following rather cryptic error message:
Kode: [Velg]
get_sock_port: getnameinfo NI_NUMERICSERV failed: ai_family not supported
Solution:
Uninstall the useless version of nmap-ncat:
Kode: [Velg]
yum erase nmap-ncatDownload the newest RPM from https://nmap.org/download.html
Install it. Example:
Kode: [Velg]
yum localinstall ncat-7.30-1.x86_64.rpmFix your
Kode: [Velg]
/etc/ssh/ssh_config as shown above.

19
Generelt teknisk / Powershell: Round to nearest integer
« på: 14. Oktober 2016, 10:07 am »
For some bizarre reason, Microsoft decided that Powershell should by default use "Banker's rounding" which by their logic is more "natural" than what people "entrenched in C" (as well as any other programming language and elementary school level mathematics) would expect.

Long story short, Powershell will by default round both 1.5 and 2.5 to 2, 3.5 and 4.5 to 4 etc.

Workaround? Define the following function to get the universally expected "round UP from .5" behaviour:

Kode: [Velg]
function round( $value, [MidpointRounding]$mode = 'AwayFromZero' ) {
  [Math]::Round( $value, $mode )
}


Kode: [Velg]
PS> [int]3.5
4
PS> [int]4.5
4
PS> round 3.5
4
PS> round 4.5
5

20
In these two code snippets, the "continue" keyword does quite the opposite of what it's supposed to:
Kode: [Velg]
PS C:\> ('a','b','c') | % { $_; continue }
a
Kode: [Velg]
PS C:\> ('a','b','c') | foreach { $_; continue }
a

When spelling the code out like you would in a sane scripting language, it works as expected:
Kode: [Velg]
PS C:\> foreach ($i in ('a','b','c')) { $i; continue }
a
b
c

Go figure.
Kode: [Velg]
PS C> $PSVersionTable.PSVersion

Major  Minor  Build  Revision
-----  -----  -----  --------
4      0      -1     -1


21
Screeps / A method for tile based path caching in Screeps
« på: 12. ſeptember 2016, 19:51 pm »

Because path finding is one of the most CPU intensive ("expensive") operations in Screeps, the need to re-use paths is a well known topic. Generally speaking, the following factors must be considered when choosing a cache strategy:

- CPU cost of learning new paths (insert)
- CPU cost of changing existing paths (update)
- CPU cost of looking up paths (select)
- CPU cost of pruning outdated entries (delete)
- Storage space

For any caching scheme to worthwhile, we must assume that each path in the cache should ideally be inserted once and selected as many times as possible. Because changes are inevitable and there is no absolute way to determine how often an individual path will be selected, the scheme must allow update and delete operations to be carried out with reasonable performance.

Most scripting languages offer built-in data types that fulfill all of these requirements but in Screeps there is another factor which severely limits the options: Storage performance.

Because all information in Screeps Memory must be serialized before storage and deserialized before use, the total number of objects in Memory soon becomes an important factor in addition to the already tight restrictions on storage space. Add to this the fact that data structures like arrays and hash tables introduce storage overhead when serialized, and it soon becomes obvious that storing fewer and bigger strings is favorable over smaller and more numerous variables.


What's in a path

An important realization is that an individual path from Pos1 to Pos2 contains much more information than just how to get from Pos1 to Pos2. Given a cluster 10 positions around Pos1 in one room and a second cluster of 10 positions around Pos2 in another room, it is fair to assume that the majority of the steps in each of the 10*10=100 possible paths between the two clusters will actually be the same. This is especially true if there is a road between the two clusters. Storing multiple instances of the same information is not only a waste of storage space (and therefore a waste of CPU resources to serialize/deserialize) but also means more information has to be processed when performing insert/update/delete and select operations.


Possible solutions

This leads to the obvious solution that information should be stored per tile so that each tile contains information about how to reach other tiles from there. At this point one might think in terms of a simple nested hash:

   cache[from_tile][to_tile] = direction

There is a number of problems with this approach. First, let's say we have 10 rooms, each room may have up to 2500 tiles (of which atleast 1% are in use). A very conservative estimate of 250 first level entries with 250 second level entries means we have 62500 objects in memory that need to be serialized and deserialized each tick. It soon becomes obvious that with all the information needed to uniquely identify each position this puts us well above the 2048K limit even before we put in any directions. One might therefore consider normalizing the information by separating information per room:
 
   cache[from_room][from_tile][to_room][to_tile] = direction

This eliminates the need to spell out each room name 250+250 times but we still have over 62500 objects in memory and use a non-trivial amount of storage space just to store structural characters such as "{},:".


Custom serialization

In response to this, a common idea is to consider other ways to serialize and deserialize Memory. I do not suggest doing this, because of several reasons:

- Performance is unlikely to be that much better unless you place severe limitations on what can be stored in memory.
- The built-in Memory access scheme relies on the possibility to access Memory in a certain way. We must either accomodate this or reimplement everything, hopefully without hurting performance.
- It is much more beneficial to address the fundamental problem and reduce the number of tiny objects we need to store. In a way, this means applying our own idea of serialization but targeting only a specific part of the data structure.


Packing information as densely as possible

One critical bit of information about the Memory object in Screeps is that it can handle UTF-16 characters. At first glance, this may seem irrelevant because room names and tile coordinates do not contain special characters, but coupled with Javascript's built-in methods for storing and retrieving UTF-16 character codes this gives us a rather convenient way to store and retrieve 16-bit values (albeit with a few important restrictions, google UTF BOM for details.)

Why is this useful? Consider the fact that a single tile coordinate can be expressed using 6+6 bits (remember, 6 bits can store a single number from 0 to 63) and a direction can be expressed using 3 bits. We have to keep in mind that certain special character codes in UTF-16 are invalid but it turns out that we can actually use the 16th bit as long as we keep those 4 highest bits in the range between 0 and 8 inclusive.

This puts us at 16 bits (2 bytes) per tile even with the direction, but we can do even better than that. If a tile happens to contain directions to multiple consecutive destinations we can choose to store them as a "span", similar to how Run Length Encoding works. Distinguishing between a span and an individual destination can be done using a "magic" direction of 0:

   code1 = x1 + (y1*50) | (1<<12) // 0x1000   Single destination with direction=1

   code1 = x1 + (y1*50) | 0       // 0x0000   Span begins at x1,y1
   code2 = x2 + (y2*50) | (3<<12) // 0x3000   Span ends at x2,y2 with direction=3

Strings of these codes can be stored for each tile, effectively reducing the number of objects to serialize/deserialize by atleast a factor of 250. For rooms with a large amount of walkable tiles, this factor can be even higher.

An alternative to the x+50y approach is to use bit shifting exclusively:

   code1 = x1 | (y1<<6) | (1<<12)

I have not bothered with benchmarking these to see which one is faster. My guess is that the difference in terms of CPU time is negligible.


Implementing access

Even if the problem of storage space and serialization/deserialization performance has been solved, there is still the non-trivial matter of implementing efficient methods to insert/update/select and delete information. These are our findings:

- The codes should always be sorted by tile address (x+50y). This eliminates the need to search the entire string to the end in both the case of a cache miss and a new insert, because the search can be aborted as soon as a higher address is encountered. The search is always carried out on the packed data structure to search the shortest string possible.

- Only when an insert/update is needed, the packed format (with spans) should be unpacked (without spans) so individual addresses can be inserted, updated or appended as needed. The unpacked data structure must be sparse, otherwise the compression operation will require a constant loop of 2500 iterations even for a string with no actual information in it.

- Only when all modifications have been made, the unpacked structure should be packed (with spans). This is the most expensive algorithm of the three in terms of CPU time because the entire unpacked string must be processed. It is therefore beneficial to put as much information into the string at once rather than making small, incremental changes.


Pseudocode for learning

Kode: [Velg]
for each tile T1 in path including start(1)
  stop if T1 is in a different room from start(2)
  get next direction as D
  fetch routing table for tile T1
  for each tile T2 in path including target(3)
    update table T1; move in direction D to reach T2
  store routing table for tile T1

1) The path will typically start with the first move, not the first tile. We need to put information into the first tile because that's where creeps will (hopefully) start later too.
2) The pathfinder may provide suboptimal results for rooms where we do not have vision. Instead of trying to deal with this in each case, simply learn the path leading to the next room and recalculate the path once we get there and see the roads etc. This also serves as a safeguard against the script spending ages on learning just one very long path.
3) The creep will probably want a path leading to the target later on, not the tiles in between, so don't forget this crucial little detail. The information about the tiles in between are just a nice bonus. You may want to try reducing the cache size and learning time by only learning the ultimate destination but in my experience this reduces the overall efficiency by causing more path searches. (See "What's in a path".)


Actual results

My current implementation runs at GCL4 with path information for 11 rooms and 40+ creeps. My total Memory is around 200 Kbytes total but I can pretty much decide how much memory to use by adjusting the cache age. My current setting is 1800 ticks, which seems to work pretty well. According to screeps-profiler, the average time to move creeps is 0.370ms, this includes pathfinding, learning, routing and the occasional fallback to moveTo/ignoreCreeps:false for collision avoidance. I use the new Pathfinder and typically see between 0 and 3 path searches per tick. Take info account that I am relatively inexperienced with both Javascript and Screeps so your results may differ. Anyway, this is what my current data structure looks like:

Kode: [Velg]
Memory
  rooms
    r Container object for routing information
      E##N## One hash per room
        xxyy Tile coordinates formatted as 4 digits, one hash per tile
          mru Game.time of last access
          local String of UTF16 characters for this room
          E##N## String of UTF16 characters for destination room
          E##N## String of UTF16 characters for destination room


Possible improvements

- This is just one possible storage structure, but I strongly recommended to store one string per combination of rooms, together with cache control data such as a MRU timestamp. This makes it trivial to discard data for any single room or tile when needed.

- Cache invalidation such as handling blocked paths resulting from new structures or using new roads is a huge topic and the full discussion is well beyond the scope of this document. One simple strategy is to introduce a small random chance to recalculate paths even if cached information exists. Another strategy is to drop random tiles from the cache to trigger recalculation.

- The suggested concept of spans form horizontal "stripes" of adjacent tiles. One possible improvement might be to form rectangular areas, either by using a more complicated algorithm to begin with or by splitting and combining adjacent "stripes" in a second pass. It is unclear if this added complexity would provide a net savings in terms of CPU performance and/or storage space.

- It might be worthwhile to store other information (such as path cost) together with the routing information in the form of trailing characters. Although the non-trivial increase in complexity and memory use would require serious consideration, this could be helpful if one wanted to write a modified pathfinder capable of taking cached information into account. 


I'm sharing this in the hope that you will find it useful. If you discover a cool way to improve the efficiency or find a stupid fault in my logic, your in-game feedback would be greatly appreciated. Preferably in the form of a message, not an invasion.


Cloulez aka. FloydATC

22
Shamelessly stolen from Rodney Barnhardt, https://www.experts-exchange.com/questions/28129776/Data-Domain-DR530-Password-Recovery.html#answer39194436

1.Connect to the serial port with the following settings:
o 9600 baud
o 8 data bits
o none/no parity
o 1 stop bit
o none/no flow control

2.Reboot the Data Domain system
3.During RAM test hit one of the following keys (BIOS version depends on which one works)
a.Delete
b.F12
c.F2
d.ESC 2
4.Enter the password, which from what you say, yours should be: d500d
5.Select Server Management (or advanced) and then Console Redirection
6.Set Legacy OS Redirection to ON (MAKE SURE NO OTHER CHANGES ARE MADE!)
7.It will look like it is rebooting, hit the TAB key at the boot screen
8.Type “p” at the prompt and enter the following password: ddrc0s (that is a zero)
9.Select “a” to append the boot-serial option
10.Make the following change by adding this to the kernel boot line: goto-bash console=ttyS0 (this is a zero)
11.Hit ENTER to save the change and then press “b” to continue booting.
12.When the reboot halts, enter the following commands
a.mv /bin/sh x
b.ln –s /bin/bash  /bin/sh
c.dd_bootmodule  --reassemble-only
13.Use the following command to get the root name: cat  /proc/cmdline
14.Depending on what is returned, you will use the following to mount the device:
a.If root=/dev/root-pl1, use dd_dg00p15
b.If root=/dev/root-pl2, use dd_dg00p5
c.If root=/dev/dd_dg00p15, use dd_dg00p15
15.Mount using the results from above. EXAMPLE: mount  /dev/dd_dg00p5
16.Edit the shadow file in vi by typing : vi  /sysroot/etc/shadow
17.Remove the encrypted password from the sysadmin account. The line will look something like this: “sysadmin:#3465@^fg/$GJITFD:13371:0:99999:7:::” After editing, it should look like the following:”sysadmin::13371:0:99999:7::: 
18.Enter :wq to save and exit the editor
19.Then enter the following commands to properly exit and reboot:
a.sync; sync; sync
b.cd/
c.umount  /sysroot
d.reboot
20.Once the system has rebooted, create a new password with the following command: user change password sysadmin

23
Generelt teknisk / Accessing the shell on DataDomain DD510
« på: 25. Juli 2016, 19:11 pm »
Shamelessly stolen from https://annurkarthik.com/category/data-storage/emc-data-domain/

Please note: use of engineering mode allows you to do major amounts of damage to your data with a frightening degree of ease and rapidity. Don’t try to access engineering mode unless you’re fully prepared to have to re-install your DataDomain – inclusive of destroying what’s left of the data on it.

Accessing SE Mode:
SSH to the DataDomain.
Login with an account that has system administrator privileges (this may be one of the default accounts your array was installed with, a local account you’ve set up for the purpose or an Active Directory managed account that has been placed into a Active Directory security-group that has been granted the system administrator role on the DataDomain
Get the array’s serial number. The easiest way to do this is type `system show serialno` at the default command prompt
Access SE mode by typing `priv set se`. You will be prompted for a password – the password is the serial number from the prior step.
At this point, your command prompt will change to “SE@<ARRAYNAME>” where “<ARRAYNAME>” will be the nodename of your DataDomain. While in this mode, an additional command-set will be enabled. These commands are accessed by typing “se”. You can get a further listing of the “se” sub-commands in much the same way you can get help at the normal system administration shell (in this particular case: by typing “se ?”).
Accessing the SE BASH Shell:
Once you’re in SE mode, the following command-sequence will allow you to access the engineering mode’s BASH shell:

Type “uname”
Type “fi st”
Type “df”
Type <CTRL>-C three times
Type “shell-escape”
At this point, a warning banner will come up to remind you of the jeopardy you’ve put your configuration in. The prompt will also change to include a warning. This is DataDomain’s way of reminding you, at every step, the danger of the access-level you’ve entered.

Once you’ve gotten the engineering BASH shell, you have pretty much unfettered access to the guts of the DataDomain. The BASH shell is pretty much the same as you’d encounter on a stock Linux system. Most of the GNU utilities you’re used to using will be there and will work the same way they do on Linux. You won’t have man pages, so, if you forget flags to a given shell command, look them up on a Linux host that has the man pages installed.

In addition to the standard Linux commands will be some DataDomain-specific commands. These are the commands that are accessible from the “se” command and its subcommands. The primary use-case for exercising these commands in BASH mode is that the BASH mode is pretty much as fully-scriptable as a root prompt on a normal Linux host. In other words, take all the danger and power of SE mode and wrap it in the sweaty-dynamite of an automated script (you can do a lot of modifications/damage by horsing the se sub-commands to a BASH `find` command or script).

24
Minecraft / VIKTIG BESKJED: Vi flytter!
« på: 09. April 2016, 19:19 pm »
Vi flytter 22.april og både serveren og forumet vil være ute av drift i MINIMUM et døgn. I verste fall, hvis ting ikke fungerer som det skal kan det gå flere dager før vi har fått alt opp og gå 100% igjen i nytt hus.

25
Arduino / Kodeklubben og Arduino - tips og triks
« på: 31. Mars 2016, 20:56 pm »

Vanlige problemer med programmet:

Spørsmål: Får ikke lastet opp.
  • Sjekk at riktig type kort er valgt under "Verktøy" | "Kort".
  • Sjekk at riktig port er valgt under "Verktøy" | "Port".
  • Hvis kretsen din trekker for mye strøm fra Arduino-kortet kan det gi pussige feil. Forsøk å kople vekk kretsen din ved å bryte forbindelsen til GND mens du laster opp.





Nyttige lenker:

Arduino hjemmeside
https://www.arduino.cc

Laste ned for Windows
https://www.arduino.cc/download_handler.php

Kjell & Company
http://www.kjell.com/no/tilbehor-til/mikrokontroller

Fritzing skisseverktøy
http://fritzing.org


26
Nyheter Software / Hardware / Switching from Apache to Lighttpd
« på: 02. Mars 2016, 22:11 pm »
Over the past few weeks I have been struggling with the latest updates to Apache which seems to have broken everything suexec related in such a way that no human is ever meant to figure it out.

The error message from Apache, should anyone be interested, is "AH1215: (60) Device is not a stream".

The interesting thing here is that the choice of web servers basically comes down to this: Do you want a huge monster where everything is supposed to "just work" but never does, OR do you want an extremely agile and configurable one where you pretty much have to hack together every feature on your own?

Lighttpd is, as you can probably guess, the latter. Which means I have to spend a few 'tuits' here and there to fix one vhost at a time. If you spot anything that isn't working right, I'd really appreciate it if you took the time to let me know.

Thanks :-)

27
Minecraft / Sv: Ny minecraft-update (1.4.2,[...] og 1.9)
« på: 01. Mars 2016, 06:37 am »
Hmm... Ikke sikker på om "tips" er rette stedet å legge det, for det er 100% tilfeldig hva som vises.
Jeg tenkte i utgangspunktet å legge det i MOTD når vi kommer litt nærmere.

Meeeen... det kunne jo være at jeg de siste par dagene før flytting bør fjerne alt annet av tips og rett og slett flashe "flyttemeldingen" om igjen og om igjen. Det kan nemlig fort vekk bli dager med nedetid, alt avhengig av fremdrift og at jeg får den nye linja til å fungere. Alt er forhåndsbestilt men Murphy's lov gjelder fortsatt.

28
Minecraft / Sv: 1.9
« på: 29. Februar 2016, 20:09 pm »
Jeg kommer til å trenge hjelp denne gangen, hold øye med ting og si ifra. Vi har solgt huset og kjøpt et nytt, samtidig holder vi på med oppgradering av kjernenettet på jobben. Gi meg beskjed når ny versjon er sluppet og hvis noen i tillegg kan gi meg et lite sammendrag av hva som er nytt så vil det garantert kutte ned tiden det vil ta å få oppdatert serveren.

Flyttingen vil også innebære et ganske stort driftsavbrudd i slutten av april men det kommer jeg tilbake til når den tid nærmer seg.

29
Feil / Sv: Internettet?
« på: 17. Februar 2016, 21:03 pm »
Prøv med en annen nettverksadapter, eller kabel

Vi har hatt overraskende mange tilfeller av problemer med ustabilt nettverk på jobben hvor løsningen har vært nye drivere til nettverkskortet i brukeren sin PC. Mange flere tilfeller enn f.eks. dårlig kabling eller defekt nettverkskort.

Helt sykt.

30
Feil / Sv: Kommer seg ikke inn.
« på: 26. Januar 2016, 22:24 pm »
Det er riktig, /approve er ikke lenger nødvendig fordi forumet nå benytter NoCaptcha som er langt bedre til å stoppe spammere fra å registrere seg. Emailen derimot er helt vesentlig.

Derfor er det litt trist når dævelskapen nekter å fungere. Tror jeg fant ut av det nå, og har aktivert ham manuelt. Gidder en av dere å gi ham beskjed?

Sider: 1 [2] 3 4 ... 52